Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XZhux-0003nL-9I for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Oct 2014 15:03:43 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XZhuw-0008LW-MQ for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Oct 2014 15:03:42 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XZhuu-0008HO-Gj for pgsql-hackers@postgresql.org; Thu, 02 Oct 2014 15:03:40 +0000 Received: from tamriel.snowman.net ([2001:4830:167b::11]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XZhur-0004eR-7k for pgsql-hackers@postgresql.org; Thu, 02 Oct 2014 15:03:38 +0000 Received: by tamriel.snowman.net (Postfix, from userid 1000) id 8295D5F7B9; Thu, 2 Oct 2014 11:03:36 -0400 (EDT) Date: Thu, 2 Oct 2014 11:03:36 -0400 From: Stephen Frost To: Robert Haas Cc: Alvaro Herrera , Mark Kirkwood , Amit Kapila , Haribabu Kommi , "pgsql-hackers@postgresql.org" Subject: Re: Per table autovacuum vacuum cost limit behaviour strange Message-ID: <20141002150336.GO28859@tamriel.snowman.net> References: <53672F63.3080400@catalyst.net.nz> <53686F22.8030300@catalyst.net.nz> <20140826161911.GE6343@eldon.alvh.no-ip.org> <20140930221644.GR5311@eldon.alvh.no-ip.org> <20141002135412.GX5311@eldon.alvh.no-ip.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HFD/Dq8JdnjNvyuv" Content-Disposition: inline In-Reply-To: X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/3.11.0-19-generic (x86_64) X-Uptime: 10:35:51 up 177 days, 54 min, 7 users, load average: 0.01, 0.03, 0.05 User-Agent: Mutt/1.5.21 (2010-09-15) X-Pg-Spam-Score: -2.9 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org --HFD/Dq8JdnjNvyuv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Robert Haas (robertmhaas@gmail.com) wrote: > On Thu, Oct 2, 2014 at 9:54 AM, Alvaro Herrera = wrote: > > Alvaro Herrera wrote: > >> So in essence what we're going to do is that the balance mechanism > >> considers only tables that don't have per-table configuration options; > >> for those that do, we will use the values configured there without any > >> changes. > >> > >> I'll see about implementing this and making sure it finds its way to > >> 9.4beta3. > > > > Here's a patch that makes it work as proposed. > > > > How do people feel about back-patching this? On one hand it seems > > there's a lot of fear of changing autovacuum behavior in back branches, > > because for many production systems it has carefully been tuned; on the > > other hand, it seems hard to believe that anyone has tuned the system to > > work sanely given how insanely per-table options behave in the current > > code. >=20 > I agree with both of those arguments. I have run into very few > customers who have used the autovacuum settings to customize behavior > for particular tables, and anyone who hasn't should see no change > (right?), so my guess is that the practical impact of the change will > be pretty limited. On the other hand, it's a clear behavior change. > Someone could have set the per-table limit to something enormous and > never suffered from that setting because it has basically no effect as > things stand right now today; and that person might get an unpleasant > surprise when they update. >=20 > I would at least back-patch it to 9.4. I could go either way on > whether to back-patch into older branches. I lean mildly in favor of > it at the moment, but with considerable trepidation. I'm fine with putting it into 9.4. I'm not sure that I see the value in changing the back-branches and then having to deal with the "well, if you're on 9.3.5 then X, but if you're on 9.3.6 then Y" or having to figure out how to deal with the documentation for this. Has there been any thought as to what pg_upgrade should do..? Thanks, Stephen --HFD/Dq8JdnjNvyuv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJULWlIAAoJEO1sijiDR2RV1KcP+gNTR9DrQvgkLIU26erjJ5DH bw7pONfCmXC9NVTngHTe1chzQ/19kUVch5bUd7j4ixWjqA7T3syW1ATWCqfv+MrO n2qlmRipY6yASK38f/Hp2q4kE+NcE7JnWOY3tllaj0jo0LpkVVJQlHZGxsgGW3Y2 e3iQ3WPZKKJJfhFKJ0jQDLLmLTPaUY1kiXC1qbNGK96UwWFeHlkkV52fbr0A07rX 3QB9tEDfvfBHbiOSw3OsSW03sbr/UQza8JgXPpmNCTXDbfWDVYxHgGTd2Mno6d1Z 9riwUVKYHrvKltvrjLIpXj+CxyDo4h8CRhWOFzMLjPG1DWk54FW4boGjIK4IV95D CGcbSrEl4V/M012Jw3ZZ+qxMZwNzWB7pjKkNuwH64xG9GhRx4I6oos4+dCQPoRVK +LZ1sSnSoJc/VtXnoKeEwvfqn8PkByh8dV7wELD/42s8jSFlWcVJPJ9mCHvlmSRO 6RAyXiQXrKqQyBpNZalfZ92tSA/Sm4wSGI/Ljk+YcdhG7816UkJhBeBCfwipIxks f5VZFdKqpLPeBFH/M5OG+QID4kTecTZ2nuTSPARx+DNDNR8eu3To2rOMTR7REKBm HEDR+XUkNXcN7HH/6Zk7ppOUl1N1zHyXBwYxtdSrPmkIuSWu49hSgfeJcvKVpNaX wSN24mvckoZmJkEg9zwx =igEV -----END PGP SIGNATURE----- --HFD/Dq8JdnjNvyuv--