From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Jeremy Schneider <schnjere@amazon.com>
Cc: Joe Conway <mail@joeconway.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Should we increase the default vacuum_cost_limit?
Date: Sat, 09 Mar 2019 12:55:54 -0500
Message-ID: <24300.1552154154@sss.pgh.pa.us> (raw)
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>
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=# set vacuum_cost_delay = '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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew.dunstan@2ndquadrant.com, david.rowley@2ndquadrant.com, jeff.janes@gmail.com, schnjere@amazon.com, mail@joeconway.com, pg@bowt.ie, pgsql-hackers@lists.postgresql.org
Subject: Re: Should we increase the default vacuum_cost_limit?
In-Reply-To: <24300.1552154154@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox