From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Jeremy Schneider <schnjere(at)amazon(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Should we increase the default vacuum_cost_limit? |
Date: | 2019-03-09 18:58:20 |
Message-ID: | c88dc1b3-9d2c-5a87-717c-0fb2497b1f22@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/9/19 12:55 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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?
>
>
Sounds good to me, seems much more likely to be future-proof.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2019-03-09 19:03:54 | Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full |
Previous Message | Julien Rouhaud | 2019-03-09 18:58:19 | Re: Checksum errors in pg_stat_database |