Horton

Re: Should we increase the default vacuum_cost_limit?

Tomas Vondra <tomas.vondra@2ndquadrant.com>

View thread View on postgr.es
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Peter Geoghegan <pg@bowt.ie>, Robert Haas <robertmhaas@gmail.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Joe Conway <mail@joeconway.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-05T12:53:07Z
Lists: pgsql-hackers 
On 3/5/19 1:14 AM, Peter Geoghegan wrote:
> On Mon, Feb 25, 2019 at 8:48 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> +1 for raising the default substantially.  In my experience, and it
>> seems others are in a similar place, nobody ever gets into trouble
>> because the default is too high, but sometimes people get in trouble
>> because the default is too low.
> 
> Does anyone want to make an argument against the idea of raising the
> default? They should speak up now.
> 

I don't know.

On the one hand I don't feel very strongly about this change, and I have
no intention to block it (because in most cases I do actually increase
the value anyway). I wonder if those with small systems will be happy
about it, though.

But on the other hand it feels a bit weird that we increase this one
value and leave all the other (also very conservative) defaults alone.


regards

-- 
Tomas Vondra                  http://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