Re: autovacuum truncate exclusive lock round two

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <kgrittn(at)mail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: autovacuum truncate exclusive lock round two
Date: 2012-12-06 03:16:23
Message-ID: 50C00E07.3070601@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/5/2012 2:00 PM, Robert Haas wrote:
> Many it'd be sensible to relate the retry time to the time spend
> vacuuming the table. Say, if the amount of time spent retrying
> exceeds 10% of the time spend vacuuming the table, with a minimum of
> 1s and a maximum of 1min, give up. That way, big tables will get a
> little more leeway than small tables, which is probably appropriate.

That sort of "dynamic" approach would indeed be interesting. But I fear
that it is going to be complex at best. The amount of time spent in
scanning heavily depends on the visibility map. The initial vacuum scan
of a table can take hours or more, but it does update the visibility map
even if the vacuum itself is aborted later. The next vacuum may scan
that table in almost no time at all, because it skips all blocks that
are marked "all visible".

So the total time the "scan" takes is no yardstick I'd use.

Jan

--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2012-12-06 04:04:58 [BUG?] lag of minRecoveryPont in archive recovery
Previous Message Bruce Momjian 2012-12-06 03:04:53 Fix for pg_upgrade status display