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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-09 06:38:04
Message-ID: 1276065484.12489.6336.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2010-06-08 at 18:35 -0400, Tom Lane 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.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2010-06-09 06:58:59 Re: Invalid YAML output from EXPLAIN
Previous Message Simon Riggs 2010-06-09 06:27:36 Re: How about closing some Open Items?