On 8/19/13 7:23 PM, Sergey Konoplev wrote:
On Thu, Aug 15, 2013 at 7:03 PM, Vlad Arkhipovwrote:
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 jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 14 of 15 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 6, '13 at 5:56a
activeAug 22, '13 at 11:15p
posts15
users5
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase