Commit dc73e25a authored by Tom Lane's avatar Tom Lane

Add commentary about varying usage of scankeys in btree code.

parent 916b2321
$Header: /cvsroot/pgsql/src/backend/access/nbtree/README,v 1.3 2000/07/21 22:14:09 tgl Exp $ $Header: /cvsroot/pgsql/src/backend/access/nbtree/README,v 1.4 2000/07/25 05:26:40 tgl Exp $
This directory contains a correct implementation of Lehman and Yao's This directory contains a correct implementation of Lehman and Yao's
high-concurrency B-tree management algorithm (P. Lehman and S. Yao, high-concurrency B-tree management algorithm (P. Lehman and S. Yao,
...@@ -119,6 +119,17 @@ In addition, the following things are handy to know: ...@@ -119,6 +119,17 @@ In addition, the following things are handy to know:
exists only to support VACUUM and allow it to delete items while exists only to support VACUUM and allow it to delete items while
it's scanning the index. it's scanning the index.
+ "ScanKey" data structures are used in two fundamentally different ways
in this code. Searches for the initial position for a scan, as well as
insertions, use scankeys in which the comparison function is a 3-way
comparator (<0, =0, >0 result). These scankeys are built within the
btree code (eg, by _bt_mkscankey()) and used by _bt_compare(). Once we
are positioned, sequential examination of tuples in a scan is done by
_bt_checkkeys() using scankeys in which the comparison functions return
booleans --- for example, int4lt might be used. These scankeys are the
ones originally passed in from outside the btree code. Same
representation, but different comparison functions!
Notes about data representation: Notes about data representation:
+ The right-sibling link required by L&Y is kept in the page "opaque + The right-sibling link required by L&Y is kept in the page "opaque
......
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