On Wed, Aug 21, 2013 at 2:33 PM, Jim Nasby <j...@nasby.net> wrote: >> 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.
Well, according to the pgstattuple log OP showed, free percent jumps from 1.82 to 70.07 in one minute, so I suppose an empty tail is inevitable anyway, so there should be locks to truncate by vacuum, if I understand things correct. -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA http://www.linkedin.com/in/grayhemp +1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979 gray...@gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
