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 26093.1276099776@sss.pgh.pa.us
Whole thread Raw
In response to Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Robert Haas <robertmhaas@gmail.com>)
Responses 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  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jun 8, 2010 at 6:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

But insert-only tables are exactly the case that Josh complained about
to start with.

> 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.

I do like the idea of using a status bit rather than FrozenXid to mark a
frozen tuple, because that eliminates the conflict between wanting to
freeze aggressively for performance reasons and wanting to preserve Xids
for forensic reasons.  But it doesn't seem to do much for Josh's
original problem.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: hstore ==> and deprecate =>
Next
From: rupendra.chulyadyo@gmail.com
Date:
Subject: Performance of Bit String