On Tue, Jun 8, 2010 at 6:35 PM, Tom Lane <tgl@sss.pgh.pa.us> 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.
Except for insert-only tables, I don't believe this is true. If you
freeze all tuples by the time the pages are marked all-visible,
perhaps via the xmin-preserving mechanism Simon suggested, then you
can use the visibility map to skip anti-wraparound vacuum as well as
regular vacuum. That sounds to me like it's accomplishing something.
Is it a complete solution? No. Is it better than what we have now?
Yes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
