On 10/03/2019 06:55, Tom Lane wrote:
Andrew Dunstan <andrew.duns...@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
Hope about keeping the default unit of ms, but converting it to a
'double' for input, but storing it as int (or long?) number of
nanoseconds. Gives finer grain of control withouthaving to specify a
unit, while still allowing calculations to be fast?
Cheers,
Gavin
