Skip to content

Commit f0a86df

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 edb5c40 commit f0a86df

File tree

2 files changed

+9
-13
lines changed

2 files changed

+9
-13
lines changed

src/backend/access/gist/gistscan.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -126,7 +126,7 @@ gistrescan(PG_FUNCTION_ARGS)
126126
* which is created on the second call and reset on later calls. Thus, in
127127
* the common case where a scan is only rescan'd once, we just put the
128128
* queue in scanCxt and don't pay the overhead of making a second memory
129-
* context. If we do rescan more than once, the first RBTree is just left
129+
* context. If we do rescan more than once, the first queue is just left
130130
* for dead until end of scan; this small wastage seems worth the savings
131131
* in the common case.
132132
*/
@@ -186,7 +186,7 @@ gistrescan(PG_FUNCTION_ARGS)
186186
ALLOCSET_DEFAULT_MAXSIZE);
187187
}
188188

189-
/* create new, empty RBTree for search queue */
189+
/* create new, empty pairing heap for search queue */
190190
oldCxt = MemoryContextSwitchTo(so->queueCxt);
191191
so->queue = pairingheap_allocate(pairingheap_GISTSearchItem_cmp, scan);
192192
MemoryContextSwitchTo(oldCxt);

src/include/access/gist_private.h

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

119115
/* Individual heap tuple to be visited */
@@ -288,8 +284,8 @@ typedef struct
288284
#define GIST_ROOT_BLKNO 0
289285

290286
/*
291-
* Before PostgreSQL 9.1, we used rely on so-called "invalid tuples" on inner
292-
* pages to finish crash recovery of incomplete page splits. If a crash
287+
* Before PostgreSQL 9.1, we used to rely on so-called "invalid tuples" on
288+
* inner pages to finish crash recovery of incomplete page splits. If a crash
293289
* happened in the middle of a page split, so that the downlink pointers were
294290
* not yet inserted, crash recovery inserted a special downlink pointer. The
295291
* semantics of an invalid tuple was that it if you encounter one in a scan,

0 commit comments

Comments
 (0)