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

Commit fd94ac5

Browse files
committed
Fix outdated comments, GIST search queue is not an RBTree anymore.
The GiST search queue is implemented as a pairing heap rather than as Red-Black Tree, since 9.5 (commit e703261). I neglected these comments in that commit.
1 parent f65764a commit fd94ac5

File tree

2 files changed

+9
-13
lines changed

2 files changed

+9
-13
lines changed

src/backend/access/gist/gistscan.c

+2-2
Original file line numberDiff line numberDiff line change
@@ -125,7 +125,7 @@ gistrescan(IndexScanDesc scan, ScanKey key, int nkeys,
125125
* which is created on the second call and reset on later calls. Thus, in
126126
* the common case where a scan is only rescan'd once, we just put the
127127
* queue in scanCxt and don't pay the overhead of making a second memory
128-
* context. If we do rescan more than once, the first RBTree is just left
128+
* context. If we do rescan more than once, the first queue is just left
129129
* for dead until end of scan; this small wastage seems worth the savings
130130
* in the common case.
131131
*/
@@ -181,7 +181,7 @@ gistrescan(IndexScanDesc scan, ScanKey key, int nkeys,
181181
ALLOCSET_DEFAULT_SIZES);
182182
}
183183

184-
/* create new, empty RBTree for search queue */
184+
/* create new, empty pairing heap for search queue */
185185
oldCxt = MemoryContextSwitchTo(so->queueCxt);
186186
so->queue = pairingheap_allocate(pairingheap_GISTSearchItem_cmp, scan);
187187
MemoryContextSwitchTo(oldCxt);

src/include/access/gist_private.h

+7-11
Original file line numberDiff line numberDiff line change
@@ -107,15 +107,11 @@ typedef struct GISTSTATE
107107
* upper index pages; this rule avoids doing extra work during a search that
108108
* ends early due to LIMIT.
109109
*
110-
* To perform an ordered search, we use an RBTree to manage the distance-order
111-
* queue. Each GISTSearchTreeItem stores all unvisited items of the same
112-
* distance; they are GISTSearchItems chained together via their next fields.
113-
*
114-
* In a non-ordered search (no order-by operators), the RBTree degenerates
115-
* to a single item, which we use as a queue of unvisited index pages only.
116-
* In this case matched heap items from the current index leaf page are
117-
* remembered in GISTScanOpaqueData.pageData[] and returned directly from
118-
* there, instead of building a separate GISTSearchItem for each one.
110+
* To perform an ordered search, we use a pairing heap to manage the
111+
* distance-order queue. In a non-ordered search (no order-by operators),
112+
* we use it to return heap tuples before unvisited index pages, to
113+
* ensure depth-first order, but all entries are otherwise considered
114+
* equal.
119115
*/
120116

121117
/* Individual heap tuple to be visited */
@@ -298,8 +294,8 @@ typedef struct
298294
#define GIST_ROOT_BLKNO 0
299295

300296
/*
301-
* Before PostgreSQL 9.1, we used rely on so-called "invalid tuples" on inner
302-
* pages to finish crash recovery of incomplete page splits. If a crash
297+
* Before PostgreSQL 9.1, we used to rely on so-called "invalid tuples" on
298+
* inner pages to finish crash recovery of incomplete page splits. If a crash
303299
* happened in the middle of a page split, so that the downlink pointers were
304300
* not yet inserted, crash recovery inserted a special downlink pointer. The
305301
* semantics of an invalid tuple was that it if you encounter one in a scan,

0 commit comments

Comments
 (0)