Re: Should we increase the default vacuum_cost_limit?

On Sat, Mar 9, 2019 at 7:58 PM Andrew Dunstan
<andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
>
> On 3/9/19 12:55 PM, Tom Lane wrote:
> >> 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.

Agreed.