Andres Freund <and...@2ndquadrant.com> writes:
> On 2014-01-23 19:29:23 -0500, Tom Lane wrote:
>> I concur with the other reports that the main problem in this test case is
>> just that the default cost delay settings throttle autovacuum so hard that
>> it has no chance of keeping up. If I reduce autovacuum_vacuum_cost_delay
>> from the default 20ms to 2ms, it seems to keep up quite nicely, on my
>> machine anyway. Probably other combinations of changes would do it too.
>> Perhaps we need to back off the default cost delay settings a bit?
>> We've certainly heard more than enough reports of table bloat in
>> heavily-updated tables. A system that wasn't hitting the updates as hard
>> as it could might not need this, but on the other hand it probably
>> wouldn't miss the I/O cycles from a more aggressive autovacuum, either.
> Yes, I think adjusting the default makes sense, most setups that have
> enough activity that costing plays a role have to greatly increase the
> values. I'd rather increase the cost limit than reduce cost delay so
> drastically though, but that's admittedly just gut feeling.
Well, I didn't experiment with intermediate values, I was just trying
to test the theory that autovac could keep up given less-extreme
throttling. I'm not taking any position on just where we need to set
the values, only that what we've got is probably too extreme.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
