Re: Remove xmin and cmin from frozen tuples

This is now in the TODO list:

* 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
becauseonly the current transaction looks at the cmin/cmax values. If the current transaction created and expired the
rowthe 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
transactioncould 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
subtransactioncompletes, 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.
Anotheridea is to store both cmin and cmax only in local memory.
 


---------------------------------------------------------------------------

Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > I'm curious to know how can you store the cmin/cmax pair completely out
> > of the tuple.  It's easy to see how to store a single identifier in each
> > tuple that would be an index to a structure in local memory.  However,
> > to eliminate both you'd have to keep a list of all tuples you have
> > created or obsoleted, with the cmin and cmax of each.  This seems like
> > an awful amount of memory.
> 
> Yeah.  I think a reasonable compromise scheme is to try to get down to
> three fields per tuple:
> 
>     xmin    same as now
>     xmax    same as now
>     cid/xvac
> 
> xvac can share storage with the command ID info as long as VACUUM FULL
> never tries to move a tuple whose originating or deleting transaction
> is still running ... which is pretty much the same restriction we had
> before.
> 
> For the command IDs, I am imagining:
> 
> if created in current transaction: use cid to store cmin
> 
> if deleted in current transaction: use cid to store cmax
> 
> if both created and deleted in current transaction: cid is an index
> into an in-memory data structure that contains cmin and cmax.
> 
> "current transaction" would have to have the loose definition that
> includes any subxact of the current top xact, but still, I think that
> the case where you need both fields is relatively uncommon.
> 
> The in-memory data structure would only need to contain an entry for
> each distinct combination of cmin and cmax used in the current xact,
> so I think we could assume that it would never get unreasonably large.
> The entries would be created "on demand" much like we do for
> multixact ids (I guess you'd want a hash table to map requested
> cmin/cmax to an existing entry ID quickly).
> 
>             regards, tom lane
> 

--  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