Reviving a very old thread, because I've run into the issue again. On Tue, May 29, 2012 at 11:58 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, May 25, 2012 at 4:06 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: >> If I invoke vacuum manually and do so with VacuumCostDelay == 0, I >> have basically declared my intentions to get this pain over with as >> fast as possible even if it might interfere with other processes. >> >> Under that condition, shouldn't it use BAS_BULKWRITE rather than >> BAS_VACUUM? The smaller ring size leads to a lot of synchronous WAL >> flushes which I think can slow the vacuum down a lot. > > Of course, an autovacuum of a really big table could run too slowly, > too, even though it's not a foreground task.
True. But almost by definition, an autovacuum is not trying to run inside a maintenance window. Would it be reasonable to upgrade the ring buffer size whenever VacuumCostDelay is zero, regardless of whether it is a manual or an auto vac? One thing I worry about is that many people may have changed autovacuum_vacuum_cost_delay from 20 directly to 0 or -1, and the accidental throttling on WAL syncs might be the only thing preventing their system from falling over each time autovac of a large table kicks in. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
