|
1 |
| -$PostgreSQL: pgsql/src/backend/access/gist/README,v 1.1 2005/09/15 16:39:15 teodor Exp $ |
| 1 | +$PostgreSQL: pgsql/src/backend/access/gist/README,v 1.2 2005/09/15 17:44:27 neilc Exp $ |
2 | 2 |
|
3 | 3 | This directory contains an implementation of GiST indexing for Postgres.
|
4 | 4 |
|
5 |
| -GiST is stands for Generalized Search Tree. It was introduced in seminal paper |
6 |
| -"Generalized Search Trees for Database Systems", 1995,Joseph M. Hellerstein, |
7 |
| -Jeffrey F. Naughton,Avi Pfeffer (http://www.sai.msu.su/~megera/postgres/gist/papers/gist.ps) and implemented by J. Hellerstein and P.Aoki in early version of |
8 |
| -PostgreSQL ( more details is available from The GiST Indexing Project at |
9 |
| -Berkeley at http://gist.cs.berkeley.edu/). As an "university" project it had a |
10 |
| -limited number of features and was in rare use. |
| 5 | +GiST stands for Generalized Search Tree. It was introduced in the seminal paper |
| 6 | +"Generalized Search Trees for Database Systems", 1995, Joseph M. Hellerstein, |
| 7 | +Jeffrey F. Naughton, Avi Pfeffer: |
11 | 8 |
|
12 |
| -Current implementation of GiST supports: |
| 9 | + http://www.sai.msu.su/~megera/postgres/gist/papers/gist.ps |
| 10 | + |
| 11 | +and implemented by J. Hellerstein and P. Aoki in an early version of |
| 12 | +PostgreSQL (more details are available from The GiST Indexing Project |
| 13 | +at Berkeley at http://gist.cs.berkeley.edu/). As a "university" |
| 14 | +project it had a limited number of features and was in rare use. |
| 15 | + |
| 16 | +The current implementation of GiST supports: |
13 | 17 |
|
14 | 18 | * Variable length keys
|
15 | 19 | * Composite keys (multi-key)
|
16 | 20 | * provides NULL-safe interface to GiST core
|
17 | 21 | * Concurrency
|
18 | 22 | * Recovery support via WAL logging
|
19 | 23 |
|
20 |
| -Concurrence algoritms implemented in PostgreSQL were developed following paper |
21 |
| -"Access Methods for Next-Generation Database Systems" by Marcel Kornaker (http://www.sai.msu.su/~megera/postgres/gist/papers/concurrency/access-methods-for-next-generation.pdf.gz). |
| 24 | +The support for concurrency implemented in PostgreSQL was developed based on the paper "Access Methods for Next-Generation Database Systems" by Marcel Kornaker: |
22 | 25 |
|
23 |
| -Original algorithms were modified by following reasons: |
| 26 | + http://www.sai.msu.su/~megera/postgres/gist/papers/concurrency/access-methods-for-next-generation.pdf.gz |
24 | 27 |
|
25 |
| -* They should be adapted to PostgreSQL conventions. For example, SEARCH |
| 28 | +The original algorithms were modified in several ways: |
| 29 | + |
| 30 | +* They should be adapted to PostgreSQL conventions. For example, the SEARCH |
26 | 31 | algorithm was considerably changed, because in PostgreSQL function search
|
27 | 32 | should return one tuple (next), not all tuples at once. Also, it should
|
28 | 33 | release page locks between calls.
|
29 |
| -* since we added support of variable length keys, it's not possible to guarantee |
| 34 | +* Since we added support for variable length keys, it's not possible to guarantee |
30 | 35 | enough free space for all keys on pages after splitting. User defined function
|
31 | 36 | picksplit doesn't have information about size of tuples (each tuple may
|
32 | 37 | contain several keys as in multicolumn index while picksplit could work with
|
33 |
| - only one key ) and pages. |
34 |
| -* We modified original INSERT algorithm for perfomance reason. In particularly, |
35 |
| - it's single-pass algorithm. |
36 |
| -* Since the paper were theoretical, some details were omited and we have to find |
37 |
| - out ourself how to solve some specific problems. |
| 38 | + only one key) and pages. |
| 39 | +* We modified original INSERT algorithm for performance reason. In particular, |
| 40 | + it is now a single-pass algorithm. |
| 41 | +* Since the papers were theoretical, some details were omitted and we |
| 42 | + have to find out ourself how to solve some specific problems. |
38 | 43 |
|
39 |
| -Because of above reasons, we have to revised interaction of GiST core and |
40 |
| -PostgreSQL WAL system. Moreover, we encountered (and solved) a problem of |
41 |
| -uncompleted insertions when recovering after crash, which was not touched in |
42 |
| -the paper. |
| 44 | +Because of the above reasons, we have to revised interaction of GiST |
| 45 | +core and PostgreSQL WAL system. Moreover, we encountered (and solved) |
| 46 | +a problem of uncompleted insertions when recovering after crash, which |
| 47 | +was not touched in the paper. |
43 | 48 |
|
44 | 49 | SEARCH ALGORITHM
|
45 |
| -Function gettuple finds tuple, which satisfy search predicate. It store their |
46 |
| -state and returns next tuple under subsequent calls. Stack contains page, |
47 |
| -its LSN and LSN of parent page and currentposition is saved between calls. |
| 50 | + |
| 51 | +Function gettuple finds a tuple which satisfies the search |
| 52 | +predicate. It store their state and returns next tuple under |
| 53 | +subsequent calls. Stack contains page, its LSN and LSN of parent page |
| 54 | +and currentposition is saved between calls. |
48 | 55 |
|
49 | 56 | gettuple(search-pred)
|
50 | 57 | if ( firsttime )
|
@@ -90,8 +97,8 @@ Penalty is used for choosing a subtree to insert; method PickSplit is used for
|
90 | 97 | the node splitting algorithm; method Union is used for propagating changes
|
91 | 98 | upward to maintain the tree properties.
|
92 | 99 |
|
93 |
| -NOTICE: We modified original INSERT algorithm for perfomance reason. In |
94 |
| -particularly, it's single-pass algorithm. |
| 100 | +NOTICE: We modified original INSERT algorithm for performance reason. In |
| 101 | +particularly, it is now a single-pass algorithm. |
95 | 102 |
|
96 | 103 | Function findLeaf is used to identify subtree for insertion. Page, in which
|
97 | 104 | insertion is proceeded, is locked as well as its parent page. Functions
|
|
0 commit comments