Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit fad7e8e

Browse files
bmomjianbmomjian
committed
Add text:
* 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 committed rows from another 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, 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.
1 parent 6c0398a commit fad7e8e

File tree

2 files changed

+41
-2
lines changed

2 files changed

+41
-2
lines changed

‎doc/TODO

Lines changed: 21 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
PostgreSQL TODO List
33
====================
44
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
5-
Last updated: Thu Sep 1 20:49:44 EDT 2005
5+
Last updated: Fri Sep 2 11:22:36 EDT 2005
66

77
The most recent version of this document can be viewed at
88
http://www.postgresql.org/docs/faqs.TODO.html.
@@ -962,6 +962,26 @@ Miscellaneous Performance
962962
could hit disk before WAL is written.
963963

964964
* Add a script to ask system configuration questions and tune postgresql.conf
965+
* Merge xmin/xmax/cmin/cmax back into three header fields
966+
967+
Before subtransactions, there used to be only three fields needed to
968+
store these four values. This was possible because only the current
969+
transaction looks at the cmin/cmax values. If the current transaction
970+
created and expired the row the fields stored where xmin (same as
971+
xmax), cmin, cmax, and if the transaction was expiring a row from a
972+
another transaction, the fields stored were xmin (cmin was not
973+
needed), xmax, and cmax. Such a system worked because a transaction
974+
could only see committed rows from another transaction. However,
975+
subtransactions can see rows from outer transactions, and once the
976+
subtransaction completes, the outer transaction continues, requiring
977+
the storage of all four fields. With subtransactions, an outer
978+
transaction can create a row, a subtransaction expire it, and when the
979+
subtransaction completes, the outer transaction still has to have
980+
proper visibility of the row, for example, for cursors.
981+
982+
One possible solution is to create a phantom cid which represents a
983+
cmin/cmax pair and is stored in local memory.
984+
965985
* Use a phantom command counter for nested subtransactions to reduce
966986
per-tuple overhead
967987
* Research storing disk pages with no alignment/padding

‎doc/src/FAQ/TODO.html

Lines changed: 20 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
<body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF">
99
<h1><a name="section_1">PostgreSQL TODO List</a></h1>
1010
<p>Current maintainer: Bruce Momjian (<a href="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</a>)<br/>
11-
Last updated: Thu Sep 1 20:49:44 EDT 2005
11+
Last updated: Fri Sep 2 11:22:36 EDT 2005
1212
</p>
1313
<p>The most recent version of this document can be viewed at<br/>
1414
<a href="http://www.postgresql.org/docs/faqs.TODO.html">http://www.postgresql.org/docs/faqs.TODO.html</a>.
@@ -867,6 +867,25 @@ <h1><a name="section_21">Miscellaneous Performance</a></h1>
867867
could hit disk before WAL is written.
868868
</p>
869869
</li><li>Add a script to ask system configuration questions and tune postgresql.conf
870+
</li><li>Merge xmin/xmax/cmin/cmax back into three header fields
871+
<p> Before subtransactions, there used to be only three fields needed to
872+
store these four values. This was possible because only the current
873+
transaction looks at the cmin/cmax values. If the current transaction
874+
created and expired the row the fields stored where xmin (same as
875+
xmax), cmin, cmax, and if the transaction was expiring a row from a
876+
another transaction, the fields stored were xmin (cmin was not
877+
needed), xmax, and cmax. Such a system worked because a transaction
878+
could only see committed rows from another transaction. However,
879+
subtransactions can see rows from outer transactions, and once the
880+
subtransaction completes, the outer transaction continues, requiring
881+
the storage of all four fields. With subtransactions, an outer
882+
transaction can create a row, a subtransaction expire it, and when the
883+
subtransaction completes, the outer transaction still has to have
884+
proper visibility of the row, for example, for cursors.
885+
</p>
886+
<p> One possible solution is to create a phantom cid which represents a
887+
cmin/cmax pair and is stored in local memory.
888+
</p>
870889
</li><li>Use a phantom command counter for nested subtransactions to reduce
871890
per-tuple overhead
872891
</li><li>Research storing disk pages with no alignment/padding

0 commit comments

Comments
 (0)