Horton

Re: Should we increase the default vacuum_cost_limit?

Joe Conway <mail@joeconway.com>

View thread View on postgr.es
From: Joe Conway <mail@joeconway.com>
To: Peter Geoghegan <pg@bowt.ie>, David Rowley <david.rowley@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-02-25T13:06:45Z
Lists: pgsql-hackers 
On 2/25/19 1:17 AM, Peter Geoghegan wrote:
> On Sun, Feb 24, 2019 at 9:42 PM David Rowley
> <david.rowley@2ndquadrant.com> wrote:
>> The current default vacuum_cost_limit of 200 seems to be 15 years old
>> and was added in f425b605f4e.
>>
>> Any supporters for raising the default?
> 
> I also think that the current default limit is far too conservative.

I agree entirely. In my experience you are usually much better off if
vacuum finishes quickly. Personally I think our default scale factors
are horrible too, especially when there are tables with large numbers of
rows.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

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