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

Tom Lane wrote:
> 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.

Considering the cost/benefits, rather than doing some optimization for
long-lived tuples, I would like to see us merge the existing
xmin/xmax/cmin/cmax values back into three storage fields like we had in
7.4 and had to expand to a full four in 8.0 to support subtransactions.
The benefit is that every row would be reduced in size by 4 bytes or 14%
for all rows:
* Merge xmin/xmax/cmin/cmax back into three header fields  Before subtransactions, there used to be only three fields
neededto  store these four values. This was possible because only the current  transaction looks at the cmin/cmax
values.If the current transaction  created and expired the row the fields stored where xmin (same as  xmax), cmin,
cmax,and if the transaction was expiring a row from a  another transaction, the fields stored were xmin (cmin was not
needed),xmax, and cmax. Such a system worked because a transaction  could only see rows from another completed
transaction.
  However, subtransactions can see rows from outer transactions, and  once the subtransaction completes, the outer
transactioncontinues,  requiring the storage of all four fields. With subtransactions, an  outer transaction can create
arow, a subtransaction expire it, and  when the subtransaction completes, the outer transaction still has  to have
propervisibility of the row's cmin, for example, for   cursors.  One possible solution is to create a phantom cid which
representsa  cmin/cmax pair and is stored in local memory.
 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073