From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jan Wieck <JanWieck(at)yahoo(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Russell Smith <mr-russ(at)pws(dot)com(dot)au>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Idea for getting rid of VACUUM FREEZE on cold pages |
Date: | 2010-06-08 22:35:00 |
Message-ID: | 11823.1276036500@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-06-08 22:45:19 | Re: Command to prune archive at restartpoints |
Previous Message | Andrew Dunstan | 2010-06-08 22:33:01 | Re: hot_standby = on |