On Tue, 2010-06-08 at 18:35 -0400, Tom Lane wrote: > Simon Riggs <si...@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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
