Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit19d561c

Browse files
committed
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
1 parentc398300 commit19d561c

File tree

2 files changed

+4
-43
lines changed

2 files changed

+4
-43
lines changed

‎doc/TODO

Lines changed: 2 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
PostgreSQL TODO List
33
====================
44
Current maintainer:Bruce Momjian (bruce@momjian.us)
5-
Last updated:Thu Feb 820:29:43 EST 2007
5+
Last updated:Thu Feb 822:37:41 EST 2007
66

77
The most recent version of this document can be viewed at
88
http://www.postgresql.org/docs/faqs.TODO.html.
@@ -1329,27 +1329,7 @@ Miscellaneous Performance
13291329
could hit disk before WAL is written.
13301330

13311331
* Add a script to ask system configuration questions and tune postgresql.conf
1332-
* Merge xmin/xmax/cmin/cmax back into three header fields
1333-
1334-
Before subtransactions, there used to be only three fields needed to
1335-
store these four values. This was possible because only the current
1336-
transaction looks at the cmin/cmax values. If the current transaction
1337-
created and expired the row the fields stored where xmin (same as
1338-
xmax), cmin, cmax, and if the transaction was expiring a row from a
1339-
another transaction, the fields stored were xmin (cmin was not
1340-
needed), xmax, and cmax. Such a system worked because a transaction
1341-
could only see rows from another completed transaction. However,
1342-
subtransactions can see rows from outer transactions, and once the
1343-
subtransaction completes, the outer transaction continues, requiring
1344-
the storage of all four fields. With subtransactions, an outer
1345-
transaction can create a row, a subtransaction expire it, and when the
1346-
subtransaction completes, the outer transaction still has to have
1347-
proper visibility of the row's cmin, for example, for cursors.
1348-
1349-
One possible solution is to create a phantom cid which represents a
1350-
cmin/cmax pair and is stored in local memory. Another idea is to
1351-
store both cmin and cmax only in local memory.
1352-
1332+
* -Merge xmin/xmax/cmin/cmax back into three header fields
13531333
* Consider ways of storing rows more compactly on disk
13541334

13551335
o Support a smaller header for short variable-length fields?

‎doc/src/FAQ/TODO.html

Lines changed: 2 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
<bodybgcolor="#FFFFFF"text="#000000"link="#FF0000"vlink="#A00000"alink="#0000FF">
99
<h1><aname="section_1">PostgreSQL TODO List</a></h1>
1010
<p>Current maintainer: Bruce Momjian (<ahref="mailto:bruce@momjian.us">bruce@momjian.us</a>)<br/>
11-
Last updated: Thu Feb 820:29:43 EST 2007
11+
Last updated: Thu Feb 822:37:41 EST 2007
1212
</p>
1313
<p>The most recent version of this document can be viewed at<br/>
1414
<ahref="http://www.postgresql.org/docs/faqs.TODO.html">http://www.postgresql.org/docs/faqs.TODO.html</a>.
@@ -1189,26 +1189,7 @@ <h1><a name="section_20">Miscellaneous Performance</a></h1>
11891189
could hit disk before WAL is written.
11901190
</p>
11911191
</li><li>Add a script to ask system configuration questions and tune postgresql.conf
1192-
</li><li>Merge xmin/xmax/cmin/cmax back into three header fields
1193-
<p> Before subtransactions, there used to be only three fields needed to
1194-
store these four values. This was possible because only the current
1195-
transaction looks at the cmin/cmax values. If the current transaction
1196-
created and expired the row the fields stored where xmin (same as
1197-
xmax), cmin, cmax, and if the transaction was expiring a row from a
1198-
another transaction, the fields stored were xmin (cmin was not
1199-
needed), xmax, and cmax. Such a system worked because a transaction
1200-
could only see rows from another completed transaction. However,
1201-
subtransactions can see rows from outer transactions, and once the
1202-
subtransaction completes, the outer transaction continues, requiring
1203-
the storage of all four fields. With subtransactions, an outer
1204-
transaction can create a row, a subtransaction expire it, and when the
1205-
subtransaction completes, the outer transaction still has to have
1206-
proper visibility of the row's cmin, for example, for cursors.
1207-
</p>
1208-
<p> One possible solution is to create a phantom cid which represents a
1209-
cmin/cmax pair and is stored in local memory. Another idea is to
1210-
store both cmin and cmax only in local memory.
1211-
</p>
1192+
</li><li>-<em>Merge xmin/xmax/cmin/cmax back into three header fields</em>
12121193
</li><li>Consider ways of storing rows more compactly on disk
12131194
<ul>
12141195
<li>Support a smaller header for short variable-length fields?

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp