Re: Idea for getting rid of VACUUM FREEZE on cold pages

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Idea for getting rid of VACUUM FREEZE on cold pages
Дата
Msg-id 11823.1276036500@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Robert Haas <robertmhaas@gmail.com>)
Re: Idea for getting rid of VACUUM FREEZE on cold pages  (marcin mank <marcin.mank@gmail.com>)
Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On Tue, 2010-06-08 at 18:03 -0400, Robert Haas wrote:
>> OK, yes, I see what you're getting at now.  There are two possible
>> ways to do freeze the tuples and keep the xmin: we can either rely on
>> the PD_ALL_VISIBLE page-level bit (as I previously proposed) or we can
>> additionally have a HEAP_XMIN_FROZEN bit as you propose here.  I am
>> not sure which way is better.

> Doing it at tuple level is more flexible and allows more aggressive
> freezing. It also works better with existing tuple visibility code.

I agree, relying on a page-level bit (or field) is unpleasant in a
number of ways.

But none of this accomplishes a damn thing towards the original goal,
which was to avoid an extra disk write associated with freezing (not
to mention an extra write for setting the transaction-committed hint
bit).  Setting a bit is no cheaper from that standpoint than changing
the xmin field.
        regards, tom lane


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: hot_standby = on
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Command to prune archive at restartpoints