Re: Idea for getting rid of VACUUM FREEZE on cold pages - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Idea for getting rid of VACUUM FREEZE on cold pages
Date
Msg-id 11823.1276036500@sss.pgh.pa.us
Whole thread Raw
In response to Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Simon Riggs <simon@2ndQuadrant.com>)
Responses 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>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: hot_standby = on
Next
From: Tom Lane
Date:
Subject: Re: Command to prune archive at restartpoints