Re: Remove xmin and cmin from frozen tuples

Tom Lane wrote:
> ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)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 needed to
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 transaction continues,
requiring the storage of all four fields. With subtransactions, an
outer transaction can create a row, a subtransaction expire it, and
when the subtransaction completes, the outer transaction still has
to have proper visibility of the row's cmin, for example, for
cursors.

One possible solution is to create a phantom cid which represents a
cmin/cmax pair and is stored in local memory.

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