From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
cc: David Rowley <david.rowley@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: <203719fc-1970-4a49-8013-eba3fd109b19@2ndQuadrant.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>
 <203719fc-1970-4a49-8013-eba3fd109b19@2ndQuadrant.com>
Comments: In-reply-to Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
	message dated "Sat, 09 Mar 2019 08:28:22 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <24299.1552154154.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 09 Mar 2019 12:55:54 -0500
Message-ID: <24300.1552154154@sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 3/9/19 4:28 AM, David Rowley wrote:
>> 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.

> Maybe we could leave the default units as msec but store it and allow
> specifying as usec. Not sure how well the GUC mechanism would cope with
> that.

I took a quick look at that and I'm afraid it'd be a mess.  GUC doesn't
really distinguish between a variable's storage unit, its default input
unit, or its default output unit (as seen in e.g. pg_settings).  Perhaps
we could split those into two or three distinct concepts, but it seems
complicated and bug-prone.  Also I think we'd still be forced into
making obviously-incompatible changes in what pg_settings shows for
this variable, since what it shows right now is integer ms.  That last
isn't a deal-breaker perhaps, but 100% compatibility isn't going to
happen this way.

The idea of converting vacuum_cost_delay into a float variable, while
keeping its native unit as ms, seems probably more feasible from a
compatibility standpoint.  There are two sub-possibilities:

1. Just do that and lose units support for the variable.  I don't
think this is totally unreasonable, because up to now ms is the
*only* workable unit for it:

regression=3D# set vacuum_cost_delay =3D '1s';
ERROR:  1000 is outside the valid range for parameter "vacuum_cost_delay" =
(0 .. 100)

Still, it'd mean that anyone who'd been explicitly setting it with
an "ms" qualifier would have to change their postgresql.conf entry.

2. Add support for units for float variables, too.  I don't think
this'd be a huge amount of work, and we'd surely have other uses
for it in the long run.

I'm inclined to go look into #2.  Anybody think this is a bad idea?

			regards, tom lane