Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 1dd9b09

Browse files
author
Neil Conway
committed
Copy-editing for GiST README.
1 parent 79fae4a commit 1dd9b09

File tree

1 file changed

+34
-27
lines changed

1 file changed

+34
-27
lines changed

src/backend/access/gist/README

Lines changed: 34 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -1,50 +1,57 @@
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 $
22

33
This directory contains an implementation of GiST indexing for Postgres.
44

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:
118

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:
1317

1418
* Variable length keys
1519
* Composite keys (multi-key)
1620
* provides NULL-safe interface to GiST core
1721
* Concurrency
1822
* Recovery support via WAL logging
1923

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:
2225

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
2427

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
2631
algorithm was considerably changed, because in PostgreSQL function search
2732
should return one tuple (next), not all tuples at once. Also, it should
2833
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
3035
enough free space for all keys on pages after splitting. User defined function
3136
picksplit doesn't have information about size of tuples (each tuple may
3237
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.
3843

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.
4348

4449
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.
4855

4956
gettuple(search-pred)
5057
if ( firsttime )
@@ -90,8 +97,8 @@ Penalty is used for choosing a subtree to insert; method PickSplit is used for
9097
the node splitting algorithm; method Union is used for propagating changes
9198
upward to maintain the tree properties.
9299

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.
95102

96103
Function findLeaf is used to identify subtree for insertion. Page, in which
97104
insertion is proceeded, is locked as well as its parent page. Functions

0 commit comments

Comments
 (0)