Done!

< * 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. < > * -Merge xmin/xmax/cmin/cmax back into three header fields

Done!
< * 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. < > * -Merge xmin/xmax/cmin/cmax back into three header fields
19d561cb · Bruce Momjian · c3983003 · 19d561cb · 19d561cb
Commit 19d561cb authored Feb 09, 2007 by Bruce Momjian
Hide whitespace changes
Inline Side-by-side

Showing with 4 additions and 43 deletions

doc/TODO doc/TODO +2 -22

doc/src/FAQ/TODO.html doc/src/FAQ/TODO.html +2 -21

No files found.
--- a/doc/TODO
+++ b/doc/TODO
@@ -2,7 +2,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:	Bruce Momjian (bruce@momjian.us)
-Last updated:		Thu Feb  8 20:29:43 EST 2007
+Last updated:		Thu Feb  8 22:37:41 EST 2007
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -1329,27 +1329,7 @@ Miscellaneous Performance
  could hit disk before WAL is written.
 * Add a script to ask system configuration questions and tune postgresql.conf
-* Merge xmin/xmax/cmin/cmax back into three header fields
+* -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.
 * Consider ways of storing rows more compactly on disk
 	o Support a smaller header for short variable-length fields?

--- a/doc/src/FAQ/TODO.html
+++ b/doc/src/FAQ/TODO.html
@@ -8,7 +8,7 @@
 <body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF">
 <h1><a name="section_1">PostgreSQL TODO List</a></h1>
 <p>Current maintainer:     Bruce Momjian (<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>)<br/>
-Last updated:           Thu Feb  8 20:29:43 EST 2007
+Last updated:           Thu Feb  8 22:37:41 EST 2007
 </p>
 <p>The most recent version of this document can be viewed at<br/>
 <a href="http://www.postgresql.org/docs/faqs.TODO.html">http://www.postgresql.org/docs/faqs.TODO.html</a>.
@@ -1189,26 +1189,7 @@ first.  There is also a developer's wiki at<br/>
  could hit disk before WAL is written.
 </p>
  </li><li>Add a script to ask system configuration questions and tune postgresql.conf
-  </li><li>Merge xmin/xmax/cmin/cmax back into three header fields
+  </li><li>-<em>Merge xmin/xmax/cmin/cmax back into three header fields</em>
-<p>  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.
-</p>
-<p>  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.
-</p>
  </li><li>Consider ways of storing rows more compactly on disk
  <ul>
    <li>Support a smaller header for short variable-length fields?