diff --git a/doc/TODO b/doc/TODO
index 2f6176d2ba277014f7486aa258e01ad1f3b17b42..b577aafeaf5f676278dc0d140f7c51012cab607d 100644
--- 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
-
- 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
* Consider ways of storing rows more compactly on disk
o Support a smaller header for short variable-length fields?
diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
index 99a0c2774517817ebcab87fe08ebb320b75000dd..5d9956c79ad51a370f0e2b99e6d0b54199de4536 100644
--- 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
-<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>-<em>Merge xmin/xmax/cmin/cmax back into three header fields</em>
</li><li>Consider ways of storing rows more compactly on disk
<ul>
<li>Support a smaller header for short variable-length fields?