Re: Remove xmin and cmin from frozen tuples - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove xmin and cmin from frozen tuples
Date
Msg-id 7861.1125542864@sss.pgh.pa.us
Whole thread Raw
In response to Remove xmin and cmin from frozen tuples  (ITAGAKI Takahiro <itagaki.takahiro@lab.ntt.co.jp>)
Responses Re: Remove xmin and cmin from frozen tuples
Re: Remove xmin and cmin from frozen tuples
List pgsql-hackers
ITAGAKI Takahiro <itagaki.takahiro@lab.ntt.co.jp> writes:
> I think it would be a waste to retain xmin and cmin for frozen tuples
> because their values represent only 'visible for all transactions'.

True, but the hard part is getting rid of the storage for them.

> I wrote a makeshift patch to compress xmin and cmin (8bytes) to
> 1-bit flag, using tuple overlaping.
> Is this idea worth trying?

I think this is incredibly ugly :-(.  It eliminates a fairly basic
assumption which is that items on a page don't overlap.  The space
savings cannot be worth the loss in testability and reliability.
To take just one problem, it is no longer possible to check an item
offset for validity against pd_upper.  If we're going to do this,
we need a more invasive patch that changes the structure of heaptuple
headers in a more fundamental way, and avoids breaking the page layout
representation.  (Something like the way Oids are now handled might
work, although there are alignment issues to worry about, and it'd
take more work on VACUUM's part to convert a tuple to frozen state.)

I'm also less than enthused about using up our last infomask bit for
a relatively unimportant purpose.  We might need that for something
bigger someday... though I can't presently guess what.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Minimally avoiding Transaction Wraparound in VLDBs
Next
From: Tom Lane
Date:
Subject: Re: Minimally avoiding Transaction Wraparound in VLDBs