Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Frankly the whole phantom commandid thing sounds more complicated. You 
> > *still*
> > need a local state data structure that *still* has to spill to disk and now
> > it's much harder to characterize how large it will grow since it depends on
> > arbitrary combinations of cmin and cmax.
> 
> Yeah, but it requires only one entry when a command processes
> arbitrarily large numbers of tuples, so in practice it's not going to
> need to spill to disk.  What Heikki wants to do will require an entry in
> local memory for *each tuple* modified by a transaction.  That will ruin
> performance on a regular basis.

Agreed.  TODO has:

        * 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.  Another idea is to
          store both cmin and cmax only in local memory.

I do see both the phantom idea and the local memory for all cmin/cmax
values.  I believe the phantom idea has the most merit.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to