From: Bruce Momjian Date: Fri, 9 Feb 2007 03:37:45 +0000 (+0000) Subject: Done! X-Git-Tag: REL8_3_BETA1~1268 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=19d561cbd00f5fd2a342fbcec4d4f5b9b28bf27d;p=postgresql 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 --- diff --git a/doc/TODO b/doc/TODO index 2f6176d2ba..b577aafeaf 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 99a0c27745..5d9956c79a 100644 --- a/doc/src/FAQ/TODO.html +++ b/doc/src/FAQ/TODO.html @@ -8,7 +8,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. @@ -1189,26 +1189,7 @@ first. There is also a developer's wiki at
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

Support a smaller header for short variable-length fields?