On Wed, Aug 21, 2013 at 2:33 PM, Jim Nasby <jim@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.ru@gmail.com
