diff options
| author | Bruce Momjian | 2007-02-09 03:37:45 +0000 |
|---|---|---|
| committer | Bruce Momjian | 2007-02-09 03:37:45 +0000 |
| commit | 19d561cbd00f5fd2a342fbcec4d4f5b9b28bf27d (patch) | |
| tree | 6b2b1118fda05af356d6526427dc4cf8f11b9c9d /doc/src | |
| parent | c398300330cb3060d50652800dbd12729ab9f5ef (diff) | |
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
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/FAQ/TODO.html | 23 |
1 files changed, 2 insertions, 21 deletions
diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html index 99a0c277451..5d9956c79ad 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? |