diff options
| author | Peter Geoghegan <pg@bowt.ie> | 2023-06-10 14:08:25 -0700 |
|---|---|---|
| committer | Peter Geoghegan <pg@bowt.ie> | 2023-06-10 14:08:25 -0700 |
| commit | d088ba5a5aa410d39b64f013e8433ad9eb3d17f1 (patch) | |
| tree | a892677da198e2821a99e0aea03b85f54bed8531 /src/backend/utils/sort | |
| parent | fe879ae3a8e0735ccb12a425e1cdbcedb2f4af81 (diff) | |
nbtree: Allocate new pages in separate function.
Split nbtree's _bt_getbuf function is two: code that read locks or write
locks existing pages remains in _bt_getbuf, while code that deals with
allocating new pages is moved to a new, dedicated function called
_bt_allocbuf. This simplifies most _bt_getbuf callers, since it is no
longer necessary for them to pass a heaprel argument. Many of the
changes to nbtree from commit 61b313e4 can be reverted. This minimizes
the divergence between HEAD/PostgreSQL 16 and earlier release branches.
_bt_allocbuf replaces the previous nbtree idiom of passing P_NEW to
_bt_getbuf. There are only 3 affected call sites, all of which continue
to pass a heaprel for recovery conflict purposes. Note that nbtree's
use of P_NEW was superficial; nbtree never actually relied on the P_NEW
code paths in bufmgr.c, so this change is strictly mechanical.
GiST already took the same approach; it has a dedicated function for
allocating new pages called gistNewBuffer(). That factor allowed commit
61b313e4 to make much more targeted changes to GiST.
Author: Peter Geoghegan <pg@bowt.ie>
Reviewed-By: Heikki Linnakangas <hlinnaka@iki.fi>
Discussion: https://postgr.es/m/CAH2-Wz=8Z9qY58bjm_7TAHgtW6RzZ5Ke62q5emdCEy9BAzwhmg@mail.gmail.com
Diffstat (limited to 'src/backend/utils/sort')
| -rw-r--r-- | src/backend/utils/sort/tuplesortvariants.c | 5 |
1 files changed, 2 insertions, 3 deletions
diff --git a/src/backend/utils/sort/tuplesortvariants.c b/src/backend/utils/sort/tuplesortvariants.c index 01881069257..eb6cfcfd002 100644 --- a/src/backend/utils/sort/tuplesortvariants.c +++ b/src/backend/utils/sort/tuplesortvariants.c @@ -207,7 +207,6 @@ tuplesort_begin_heap(TupleDesc tupDesc, Tuplesortstate * tuplesort_begin_cluster(TupleDesc tupDesc, Relation indexRel, - Relation heaprel, int workMem, SortCoordinate coordinate, int sortopt) { @@ -261,7 +260,7 @@ tuplesort_begin_cluster(TupleDesc tupDesc, arg->tupDesc = tupDesc; /* assume we need not copy tupDesc */ - indexScanKey = _bt_mkscankey(indexRel, heaprel, NULL); + indexScanKey = _bt_mkscankey(indexRel, NULL); if (arg->indexInfo->ii_Expressions != NULL) { @@ -362,7 +361,7 @@ tuplesort_begin_index_btree(Relation heapRel, arg->enforceUnique = enforceUnique; arg->uniqueNullsNotDistinct = uniqueNullsNotDistinct; - indexScanKey = _bt_mkscankey(indexRel, heapRel, NULL); + indexScanKey = _bt_mkscankey(indexRel, NULL); /* Prepare SortSupport data for each column */ base->sortKeys = (SortSupport) palloc0(base->nKeys * |