Horton

Re: Should we increase the default vacuum_cost_limit?

Andrew Dunstan <andrew.dunstan@2ndquadrant.com>

View thread View on postgr.es
From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: David Rowley <david.rowley@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Janes <jeff.janes@gmail.com>, Jeremy Schneider <schnjere@amazon.com>, Joe Conway <mail@joeconway.com>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-09T01:29:14Z
Lists: pgsql-hackers 
On 3/8/19 6:47 PM, David Rowley wrote:
> On Sat, 9 Mar 2019 at 07:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Jeff Janes <jeff.janes@gmail.com> writes:
>>> Now that this is done, the default value is only 5x below the hard-coded
>>> maximum of 10,000.
>>> This seems a bit odd, and not very future-proof.  Especially since the
>>> hard-coded maximum appears to have no logic to it anyway, at least none
>>> that is documented.  Is it just mindless nannyism?
>> Hm.  I think the idea was that rather than setting it to "something very
>> large", you'd want to just disable the feature via vacuum_cost_delay.
>> But I agree that the threshold for what is ridiculously large probably
>> ought to be well more than 5x the default, and maybe it is just mindless
>> nannyism to have a limit less than what the implementation can handle.
> Yeah, +1 to increasing it.  I imagine that the 10,000 limit would not
> allow people to explore the upper limits of a modern PCI-E SSD with
> the standard delay time and dirty/miss scores.  Also, it doesn't seem
> entirely unreasonable that someone somewhere might also want to
> fine-tune the hit/miss/dirty scores so that they're some larger factor
> apart from each other the standard scores are. The 10,000 limit does
> not allow much wiggle room for that.
>


Increase it to what?


cheers


andrew



-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Allow fractional input values for integer GUCs, and improve rounding logic.

  2. Reduce the default value of autovacuum_vacuum_cost_delay to 2ms.

  3. Revert "Increase the default vacuum_cost_limit from 200 to 2000"

  4. Convert [autovacuum_]vacuum_cost_delay into floating-point GUCs.

  5. Include GUC's unit, if it has one, in out-of-range error messages.

  6. Disallow NaN as a value for floating-point GUCs.

  7. Increase the default vacuum_cost_limit from 200 to 2000