1berry/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Done!

Browse Source 
< * 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:
Bruce Momjian 2007-02-09 03:37:45 +00:00
parent c398300330
commit 19d561cbd0
2 changed files with 4 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
doc/TODO
View File

@ -2,7 +2,7 @@
PostgreSQL TODO List PostgreSQL TODO List
==================== ====================
Current maintainer: Bruce Momjian (bruce@momjian.us) 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 The most recent version of this document can be viewed at
http://www.postgresql.org/docs/faqs.TODO.html. http://www.postgresql.org/docs/faqs.TODO.html.
@ -1329,27 +1329,7 @@ Miscellaneous Performance
could hit disk before WAL is written. could hit disk before WAL is written.
* Add a script to ask system configuration questions and tune postgresql.conf * 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 * Consider ways of storing rows more compactly on disk
o Support a smaller header for short variable-length fields? o Support a smaller header for short variable-length fields?

23
doc/src/FAQ/TODO.html
View File

@ -8,7 +8,7 @@
<body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF"> <body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF">
<h1><a name="section_1">PostgreSQL TODO List</a></h1> <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/> <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>
<p>The most recent version of this document can be viewed at<br/> <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>. <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. could hit disk before WAL is written.
</p> </p>
</li><li>Add a script to ask system configuration questions and tune postgresql.conf </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 </li><li>Consider ways of storing rows more compactly on disk
<ul> <ul>
<li>Support a smaller header for short variable-length fields? <li>Support a smaller header for short variable-length fields?