database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-09 06:21:09 +03:00
Code Activity

Make source code READMEs more consistent. Add CVS tags to all README files.

Browse Source
This commit is contained in:
Bruce Momjian
2008-03-20 17:55:15 +00:00
parent 27dfc11d67
commit 4e228447aa
22 changed files with 148 additions and 93 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
src/backend/access/nbtree/README
View File

@@ -1,4 +1,7 @@
$PostgreSQL: pgsql/src/backend/access/nbtree/README,v 1.18 2007/09/12 22:10:26 tgl Exp $
$PostgreSQL: pgsql/src/backend/access/nbtree/README,v 1.19 2008/03/20 17:55:14 momjian Exp $
Btree Indexing
--------------
This directory contains a correct implementation of Lehman and Yao's
high-concurrency B-tree management algorithm (P. Lehman and S. Yao,
@@ -8,7 +11,7 @@ use a simplified version of the deletion logic described in Lanin and
Shasha (V. Lanin and D. Shasha, A Symmetric Concurrent B-Tree Algorithm,
Proceedings of 1986 Fall Joint Computer Conference, pp 380-389).
The Lehman and Yao algorithm and insertions
The Lehman and Yao Algorithm and Insertions
-------------------------------------------
We have made the following changes in order to incorporate the L&Y algorithm
@@ -125,7 +128,7 @@ each of the resulting pages. Note we must include the incoming item in
this calculation, otherwise it is possible to find that the incoming
item doesn't fit on the split page where it needs to go!
The deletion algorithm
The Deletion Algorithm
----------------------
Before deleting a leaf item, we get a super-exclusive lock on the target
@@ -320,7 +323,7 @@ positives, so long as it never gives a false negative. This makes it
possible to implement the test with a small counter value stored on each
index page.
On-the-fly deletion of index tuples
On-the-Fly Deletion Of Index Tuples
-----------------------------------
If a process visits a heap tuple and finds that it's dead and removable
@@ -357,7 +360,7 @@ and so cannot remove the heap tuple. This is another reason why
btbulkdelete has to get super-exclusive lock on every leaf page, not only
the ones where it actually sees items to delete.
WAL considerations
WAL Considerations
------------------
The insertion and deletion algorithms in themselves don't guarantee btree
@@ -398,7 +401,7 @@ of the WAL entry.) If the parent page becomes half-dead but is not
immediately deleted due to a subsequent crash, there is no loss of
consistency, and the empty page will be picked up by the next VACUUM.
Other things that are handy to know
Other Things That Are Handy to Know
-----------------------------------
Page zero of every btree is a meta-data page. This page stores the
@@ -443,7 +446,7 @@ original search scankey is consulted as each index entry is sequentially
scanned to decide whether to return the entry and whether the scan can
stop (see _bt_checkkeys()).
Notes about data representation
Notes About Data Representation
-------------------------------
The right-sibling link required by L&Y is kept in the page "opaque
@@ -477,7 +480,7 @@ item is irrelevant, and need not be stored at all. This arrangement
corresponds to the fact that an L&Y non-leaf page has one more pointer
than key.
Notes to operator class implementors
Notes to Operator Class Implementors
------------------------------------
With this implementation, we require each supported combination of