On Tue, 2010-06-08 at 18:35 -0400, Tom Lane wrote:
> 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.
No, it doesn't of itself, but if you raise a complaint then we must
first address the complaint as a sub-topic before we continue the main
discussion around $TOPIC. My proposal removes the barrier that early
freezing would overwrite xmin values, so early freezing need not have
any negative effects.
The general idea is to hide the "third write" (freezing) on a tuple by
making it happen at the same time as another tuple's "second
write" (hint bit setting).
I'm happy to let that continue by the OPs.
-- Simon Riggs www.2ndQuadrant.com
