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

From: marcin mank <marcin(dot)mank(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages
Date: 2010-06-09 10:45:32
Message-ID: AANLkTins8pinYCPYpnVZTfnTrrnbJ_OZSV7jJEfP4t2W@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 9, 2010 at 12:35 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)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.
>

Could a tuple wih the bit set be considered frozen already? Would we
actually ever need to rewrite the xmin, even for anti-wraparound
reasons?

Greetings
Marcin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-06-09 10:51:41 Re: hstore ==> and deprecate =>
Previous Message Greg Stark 2010-06-09 10:41:29 Re: hstore ==> and deprecate =>