mirror of https://github.com/postgres/postgres
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
This commit is contained in:
parent
c398300330
commit
19d561cbd0
24
doc/TODO
24
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?
|
||||
|
|
|
@ -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?
|
||||
|
|
Loading…
Reference in New Issue