Skip to content

P
Postgres FD Implementation
Commit fad7e8ed authored by Bruce Momjian's avatar Bruce Momjian
Browse files
Options

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.
parent 6c0398a7
Show whitespace changes
Inline Side-by-side
Showing with 41 additions and 2 deletions
doc/TODO
View file @ fad7e8ed
......@@ -2,7 +2,7 @@
PostgreSQL TODO List
====================
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
Last updated: Thu Sep 1 20:49:44 EDT 2005
Last updated: Fri Sep 2 11:22:36 EDT 2005
The most recent version of this document can be viewed at
http://www.postgresql.org/docs/faqs.TODO.html.
......@@ -962,6 +962,26 @@ 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 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.
* Use a phantom command counter for nested subtransactions to reduce
per-tuple overhead
* Research storing disk pages with no alignment/padding
......
doc/src/FAQ/TODO.html
View file @ fad7e8ed
......@@ -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:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</a>)<br/>
Last updated: Thu Sep 1 20:49:44 EDT 2005
Last updated: Fri Sep 2 11:22:36 EDT 2005
</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>.
......@@ -867,6 +867,25 @@ first.
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 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.
</p>
<p> One possible solution is to create a phantom cid which represents a
cmin/cmax pair and is stored in local memory.
</p>
</li><li>Use a phantom command counter for nested subtransactions to reduce
per-tuple overhead
</li><li>Research storing disk pages with no alignment/padding
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment