Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYeMd-0002jp-P2 for pgsql-docs@arkaria.postgresql.org; Tue, 12 May 2020 23:31:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jYeMc-0002t0-Mu for pgsql-docs@arkaria.postgresql.org; Tue, 12 May 2020 23:31:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYeMc-0002ss-Gw for pgsql-docs@lists.postgresql.org; Tue, 12 May 2020 23:31:06 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYeMV-00031E-QI for pgsql-docs@lists.postgresql.org; Tue, 12 May 2020 23:31:06 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1jYeMS-0004B3-JG; Tue, 12 May 2020 19:30:56 -0400 Date: Tue, 12 May 2020 19:30:56 -0400 From: Bruce Momjian To: Tom Lane Cc: "David G. Johnston" , yigongh@gmail.com, pgsql-docs@lists.postgresql.org Subject: Re: The suggestion of reducing autovacuum_vacuum_cost_delay should be documented Message-ID: <20200512233056.GF4666@momjian.us> References: <158927918783.656.11973436145559215458@wrigleys.postgresql.org> <20200512214014.GD4666@momjian.us> <20200512214101.GA21408@momjian.us> <20200512224520.GE4666@momjian.us> <23940.1589325967@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <23940.1589325967@sss.pgh.pa.us> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, May 12, 2020 at 07:26:07PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Tue, May 12, 2020 at 03:38:16PM -0700, David G. Johnston wrote: > >> The proposal is to document in versions 9.4 to 11 that the recommended value > >> for the setting is 2ms while for reasons of continuity the default in these > >> versions is 20ms. > >> I don't really see any harm in it.  Its not like the choice to reduce the value > >> was made because of new features introduced in 12 - it was a re-evaluation of a > >> 15 year old default. > > > Well, we really need to have some general discussion about whether > > changing defaults in major releases should trigger a mention to change > > the defaults in back branches. This is something that would have to be > > discussed on the hackers list. > > It's not immediately obvious that the new default value established in > version N is appropriate for version N-minus-several. Certainly, whatever > testing was done to justify the new default wouldn't have been done on old > versions; and there might have been relevant changes. > > In short: nope, I'm not on board with blindly back-patching such > recommendations. That was my analysis too. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +