On 8/19/13 7:23 PM, Sergey Konoplev wrote:
On Thu, Aug 15, 2013 at 7:03 PM, Vlad Arkhipov<arhi...@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'd only 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*. If there's no bloat to begin with,
getting the lock to truncate will be a non-issue.
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
