On 3/9/19 12:55 PM, 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? > >
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
