Re: autovacuum not prioritising for-wraparound tables

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: autovacuum not prioritising for-wraparound tables
Дата
Msg-id 1359581316.46973.YahooMailNeo@web162903.mail.bf1.yahoo.com
обсуждение исходный текст
Ответ на Re: autovacuum not prioritising for-wraparound tables  (Jim Nasby <jim@nasby.net>)
Ответы Re: autovacuum not prioritising for-wraparound tables  (Jim Nasby <jim@nasby.net>)
Список pgsql-hackers
Jim Nasby <jim@nasby.net> wrote:

> the only reason to freeze is XID wrap

The conclusions you draw seem to be based on a slightly different
premise than stated here; the conclusions are only supported by the
assumption that "the only reason to freeze at any particular moment
is to assure that all tuples are frozen in time to prevent
transaction wraparound."  In a mostly write-only database, that has
to happen for nearly every tuple at some point -- but *which* point
is best is not necessarily "as late as possible".

> then the *ideal* time to start a freeze vacuum on a table is so
> that the vacuum would end *exactly* as we were about to hit XID
> wrap.

For a tuple which you know is going to survive long enough to be
frozen, the *ideal* time to freeze a tuple, from a performance
standpoint, is when the tuple is written, to eliminate a separate
WAL-log operation.  The *next best* time to freeze is when the hint
bits are set, to avoid a separate page write.  If you are doing
differential backups, the *third best* time to freeze is before the
first differential backup of the tuple, to avoid a separate backup
after the freeze.  And so on.

-Kevin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: plpgsql versus SPI plan abstraction
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: plpgsql versus SPI plan abstraction