From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
        Jeff Janes <jeff.janes@gmail.com>,
        Jeremy Schneider <schnjere@amazon.com>,
        Joe Conway <mail@joeconway.com>, Peter Geoghegan <pg@bowt.ie>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Should we increase the default vacuum_cost_limit?
In-reply-to: 
 <CAKJS1f8s5Cxat65_-uE97oUpoonO3p_2rFMf-cKA7kpAaS1-OA@mail.gmail.com>
References: 
 <CAKJS1f_YbXC2qTMPyCbmsPiKvZYwpuQNQMohiRXLj1r=8_rYvw@mail.gmail.com>
 <CAH2-Wz=WQ9ju6sjPF7RcW0g6NPXAenZeC5qVme6uj+eMRw5q2g@mail.gmail.com>
 <241b80ab-7af0-c606-7b2c-b0a5d6be696a@joeconway.com>
 <CAKJS1f_5xofbg0K16MkhQPeCXV6oGCuD2SVcV76OW7ydFDHDkw@mail.gmail.com>
 <df548503-d261-d8c4-97d0-61be6617df41@2ndQuadrant.com>
 <4a068b09-5a6f-e975-07c9-2333fcef0a8a@amazon.com>
 <30411a5b-ef11-71ef-e9ee-4d26ef3fd0c0@2ndQuadrant.com>
 <CAMkU=1zM7sK9Xo2jjwCLj-t+GHR5nQJnPyFUp+puBiFpOQ7aBA@mail.gmail.com>
 <21034.1552068630@sss.pgh.pa.us>
 <CAKJS1f9wbS+SzEDUXyMuLCsNgwMH=1Ztj3QE3WxuKdJtbqrOEA@mail.gmail.com>
 <13d143dd-0a44-0c16-218c-bc924b5922f0@2ndQuadrant.com>
 <26656.1552096451@sss.pgh.pa.us> <28720.1552101086@sss.pgh.pa.us>
 <CAKJS1f8s5Cxat65_-uE97oUpoonO3p_2rFMf-cKA7kpAaS1-OA@mail.gmail.com>
Comments: In-reply-to David Rowley <david.rowley@2ndquadrant.com>
	message dated "Sat, 09 Mar 2019 22:28:12 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21147.1552149096.1@sss.pgh.pa.us>
Date: Sat, 09 Mar 2019 11:31:36 -0500
Message-ID: <21148.1552149096@sss.pgh.pa.us>
Precedence: bulk

David Rowley <david.rowley@2ndquadrant.com> writes:
> I agree that vacuum_cost_delay might not be granular enough, however.
> If we're going to change the vacuum_cost_delay into microseconds, then
> I'm a little concerned that it'll silently break existing code that
> sets it.  Scripts that do manual off-peak vacuums are pretty common
> out in the wild.

True.  Perhaps we could keep the units as ms but make it a float?
Not sure if the "units" logic can cope though.

> My vote is to 10x the maximum for vacuum_cost_limit and consider
> changing how it all works in PG13.  If nothing happens before this
> time next year then we can consider making vacuum_cost_delay a
> microseconds GUC.

I'm not really happy with the idea of changing the defaults in this area
and then changing them again next year.  That's going to lead to a lot
of confusion, and a mess for people who may have changed (some) of
the settings manually.

			regards, tom lane