Re: autovacuum truncate exclusive lock round two

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: autovacuum truncate exclusive lock round two
Дата
Msg-id 50C00E07.3070601@Yahoo.com
обсуждение исходный текст
Ответ на Re: autovacuum truncate exclusive lock round two  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: autovacuum truncate exclusive lock round two
Re: autovacuum truncate exclusive lock round two
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Fix for pg_upgrade status display
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: [BUG?] lag of minRecoveryPont in archive recovery