From: | Sergey Konoplev <gray(dot)ru(at)gmail(dot)com> |
---|---|
To: | Jim Nasby <jim(at)nasby(dot)net> |
Cc: | Vlad Arkhipov <arhipov(at)dc(dot)baikal(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: System catalog vacuum issues |
Date: | 2013-08-22 23:14:35 |
Message-ID: | CAL_0b1vX_1mBMiByfLtLt-HnnDjcKcaKkofYYUTtDDnQPf01TQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 21, 2013 at 2:33 PM, Jim Nasby <jim(at)nasby(dot)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(dot)ru(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2013-08-22 23:21:15 | Re: PL/pgSQL PERFORM with CTE |
Previous Message | Tom Lane | 2013-08-22 22:41:35 | Re: Does larger i/o size make sense? |