Re: autovacuum truncate exclusive lock round two - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: autovacuum truncate exclusive lock round two
Date
Msg-id 50C00E07.3070601@Yahoo.com
Whole thread Raw
In response to Re: autovacuum truncate exclusive lock round two  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: autovacuum truncate exclusive lock round two
Re: autovacuum truncate exclusive lock round two
List 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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Fix for pg_upgrade status display
Next
From: Kyotaro HORIGUCHI
Date:
Subject: [BUG?] lag of minRecoveryPont in archive recovery