From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Foreground vacuum and buffer access strategy |
Date: | 2013-08-13 03:47:55 |
Message-ID: | CAMkU=1ya0uu=vwsqND662LsWqPy+=ktgA8gMsQu9UFH0MdTFtQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Reviving a very old thread, because I've run into the issue again.
On Tue, May 29, 2012 at 11:58 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, May 25, 2012 at 4:06 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2013-08-13 05:26:23 | Re: StrategyGetBuffer optimization, take 2 |
Previous Message | Bruce Momjian | 2013-08-13 03:31:38 | Re: [BUGS] BUG #8335: trim() un-document behaviour |