Re: System catalog vacuum issues - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: System catalog vacuum issues
Date
Msg-id 52153235.3000607@nasby.net
Whole thread Raw
In response to Re: System catalog vacuum issues  (Sergey Konoplev <gray.ru@gmail.com>)
Responses Re: System catalog vacuum issues  (Sergey Konoplev <gray.ru@gmail.com>)
List pgsql-hackers
On 8/19/13 7:23 PM, Sergey Konoplev wrote:
> On Thu, Aug 15, 2013 at 7:03 PM, Vlad Arkhipov<arhipov@dc.baikal.ru>  wrote:
>>> >>Do you have some processes that intensively create tables or columns
>>> >>and then delete them or create them in transaction and rollback the
>>> >>transaction?
>>> >>
>> >There are many processes that create and drop temporary tables.
> That is the problem. Exactly what Jim was writing about. Autovacuum
> have no chance to clean dead tuples at the end of the table because
> they are created too intensively. In the latest versions autovacuum
> behaves so it would stop working when a concurrent lock is acquired.
> As he suggested you should use vacuum in cron, however it might make
> other procecess, that create/drop tables to wait.

Hrm... even if vacuum cost delay is set? I recall some talk about doing some minimal waiting for the lock, but thought
that'donly happen if cost delay was 0.
 

That really doesn't matter though. The whole idea of a cron'd vacuum is to *stop bloat from happening to begin with*.
Ifthere's no bloat to begin with, getting the lock to truncate will be a non-issue.
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: plpgsql_check_function - rebase for 9.3
Next
From: Jim Nasby
Date:
Subject: Re: proposal: lob conversion functionality