Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit2a96909

Browse files
committed
tableam: Support for an index build's initial table scan(s).
To support building indexes over tables of different AMs, the scans todo so need to be routed through the table AM. While moving a fairamount of code, nearly all the changes are just moving code to below acallback.Currently the range based interface wouldn't make much sense for nonblock based table AMs. But that seems aceptable for now.Author: Andres FreundDiscussion:https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
1 parent12bb35f commit2a96909

File tree

14 files changed

+1012
-936
lines changed

14 files changed

+1012
-936
lines changed

‎contrib/amcheck/verify_nbtree.c

Lines changed: 20 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -23,9 +23,9 @@
2323
*/
2424
#include"postgres.h"
2525

26-
#include"access/heapam.h"
2726
#include"access/htup_details.h"
2827
#include"access/nbtree.h"
28+
#include"access/table.h"
2929
#include"access/tableam.h"
3030
#include"access/transam.h"
3131
#include"access/xact.h"
@@ -142,7 +142,7 @@ static void bt_tuple_present_callback(Relation index, HeapTuple htup,
142142
Datum*values,bool*isnull,
143143
booltupleIsAlive,void*checkstate);
144144
staticIndexTuplebt_normalize_tuple(BtreeCheckState*state,
145-
IndexTupleitup);
145+
IndexTupleitup);
146146
staticboolbt_rootdescend(BtreeCheckState*state,IndexTupleitup);
147147
staticinlinebooloffset_is_negative_infinity(BTPageOpaqueopaque,
148148
OffsetNumberoffset);
@@ -387,10 +387,10 @@ bt_check_every_level(Relation rel, Relation heaprel, bool heapkeyspace,
387387

388388
/*
389389
* Register our own snapshot in !readonly case, rather than asking
390-
*IndexBuildHeapScan() to do this for us later. This needs to happen
391-
* before index fingerprinting begins, so we can later be certain that
392-
* index fingerprinting should have reached all tuples returned by
393-
*IndexBuildHeapScan().
390+
*table_index_build_scan() to do this for us later. This needs to
391+
*happenbefore index fingerprinting begins, so we can later be
392+
*certain thatindex fingerprinting should have reached all tuples
393+
*returned by table_index_build_scan().
394394
*
395395
* In readonly case, we also check for problems with missing
396396
* downlinks. A second Bloom filter is used for this.
@@ -525,18 +525,19 @@ bt_check_every_level(Relation rel, Relation heaprel, bool heapkeyspace,
525525
}
526526

527527
/*
528-
* Create our own scan for IndexBuildHeapScan(), rather than getting
529-
* it to do so for us. This is required so that we can actually use
530-
* the MVCC snapshot registered earlier in !readonly case.
528+
* Create our own scan for table_index_build_scan(), rather than
529+
* getting it to do so for us. This is required so that we can
530+
* actually use the MVCC snapshot registered earlier in !readonly
531+
* case.
531532
*
532-
* Note thatIndexBuildHeapScan() calls heap_endscan() for us.
533+
* Note thattable_index_build_scan() calls heap_endscan() for us.
533534
*/
534-
scan=table_beginscan_strat(state->heaprel,/* relation */
535+
scan=table_beginscan_strat(state->heaprel,/* relation */
535536
snapshot,/* snapshot */
536-
0,/* number of keys */
537+
0,/* number of keys */
537538
NULL,/* scan key */
538539
true,/* buffer access strategy OK */
539-
true);/* syncscan OK? */
540+
true);/* syncscan OK? */
540541

541542
/*
542543
* Scan will behave as the first scan of a CREATE INDEX CONCURRENTLY
@@ -565,8 +566,8 @@ bt_check_every_level(Relation rel, Relation heaprel, bool heapkeyspace,
565566
RelationGetRelationName(state->rel),
566567
RelationGetRelationName(state->heaprel));
567568

568-
IndexBuildHeapScan(state->heaprel,state->rel,indexinfo, true,
569-
bt_tuple_present_callback, (void*)state,scan);
569+
table_index_build_scan(state->heaprel,state->rel,indexinfo, true,
570+
bt_tuple_present_callback, (void*)state,scan);
570571

571572
ereport(DEBUG1,
572573
(errmsg_internal("finished verifying presence of "INT64_FORMAT" tuples from table \"%s\" with bitset %.2f%% set",
@@ -814,7 +815,7 @@ bt_check_level_from_leftmost(BtreeCheckState *state, BtreeLevel level)
814815
* (Limited to heapallindexed readonly callers.)
815816
*
816817
* This is also where heapallindexed callers use their Bloom filter to
817-
* fingerprint IndexTuples for laterIndexBuildHeapScan() verification.
818+
* fingerprint IndexTuples for latertable_index_build_scan() verification.
818819
*
819820
* Note: Memory allocated in this routine is expected to be released by caller
820821
* resetting state->targetcontext.
@@ -1776,7 +1777,7 @@ bt_downlink_missing_check(BtreeCheckState *state)
17761777
}
17771778

17781779
/*
1779-
* Per-tuple callback fromIndexBuildHeapScan, used to determine if index has
1780+
* Per-tuple callback fromtable_index_build_scan, used to determine if index has
17801781
* all the entries that definitely should have been observed in leaf pages of
17811782
* the target index (that is, all IndexTuples that were fingerprinted by our
17821783
* Bloom filter). All heapallindexed checks occur here.
@@ -1801,7 +1802,7 @@ bt_downlink_missing_check(BtreeCheckState *state)
18011802
* verification, just in case it's a cross-page invariant issue, though that
18021803
* isn't particularly likely.
18031804
*
1804-
*IndexBuildHeapScan() expects to be able to find the root tuple when a
1805+
*table_index_build_scan() expects to be able to find the root tuple when a
18051806
* heap-only tuple (the live tuple at the end of some HOT chain) needs to be
18061807
* indexed, in order to replace the actual tuple's TID with the root tuple's
18071808
* TID (which is what we're actually passed back here). The index build heap
@@ -1817,7 +1818,7 @@ bt_downlink_missing_check(BtreeCheckState *state)
18171818
* setting will probably also leave the index in a corrupt state before too
18181819
* long, the problem is nonetheless that there is heap corruption.)
18191820
*
1820-
* Heap-only tuple handling withinIndexBuildHeapScan() works in a way that
1821+
* Heap-only tuple handling withintable_index_build_scan() works in a way that
18211822
* helps us to detect index tuples that contain the wrong values (values that
18221823
* don't match the latest tuple in the HOT chain). This can happen when there
18231824
* is no superseding index tuple due to a faulty assessment of HOT safety,

‎contrib/bloom/blinsert.c

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -14,6 +14,7 @@
1414

1515
#include"access/genam.h"
1616
#include"access/generic_xlog.h"
17+
#include"access/tableam.h"
1718
#include"catalog/index.h"
1819
#include"miscadmin.h"
1920
#include"storage/bufmgr.h"
@@ -69,7 +70,7 @@ initCachedPage(BloomBuildState *buildstate)
6970
}
7071

7172
/*
72-
* Per-tuple callbackfrom IndexBuildHeapScan.
73+
* Per-tuple callbackfor table_index_build_scan.
7374
*/
7475
staticvoid
7576
bloomBuildCallback(Relationindex,HeapTuplehtup,Datum*values,
@@ -141,9 +142,9 @@ blbuild(Relation heap, Relation index, IndexInfo *indexInfo)
141142
initCachedPage(&buildstate);
142143

143144
/* Do the heap scan */
144-
reltuples=IndexBuildHeapScan(heap,index,indexInfo, true,
145-
bloomBuildCallback, (void*)&buildstate,
146-
NULL);
145+
reltuples=table_index_build_scan(heap,index,indexInfo, true,
146+
bloomBuildCallback, (void*)&buildstate,
147+
NULL);
147148

148149
/* Flush last page if needed (it will be, unless heap was empty) */
149150
if (buildstate.count>0)

‎doc/src/sgml/indexam.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -238,7 +238,7 @@ ambuild (Relation heapRelation,
238238
but is empty. It must be filled in with whatever fixed data the
239239
access method requires, plus entries for all tuples already existing
240240
in the table. Ordinarily the <function>ambuild</function> function will call
241-
<function>IndexBuildHeapScan()</function> to scan the table for existing tuples
241+
<function>table_index_build_scan()</function> to scan the table for existing tuples
242242
and compute the keys that need to be inserted into the index.
243243
The function must return a palloc'd struct containing statistics about
244244
the new index.

‎src/backend/access/brin/brin.c

Lines changed: 10 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,7 @@
2323
#include"access/reloptions.h"
2424
#include"access/relscan.h"
2525
#include"access/table.h"
26+
#include"access/tableam.h"
2627
#include"access/xloginsert.h"
2728
#include"catalog/index.h"
2829
#include"catalog/pg_am.h"
@@ -587,7 +588,7 @@ brinendscan(IndexScanDesc scan)
587588
}
588589

589590
/*
590-
* Per-heap-tuple callback forIndexBuildHeapScan.
591+
* Per-heap-tuple callback fortable_index_build_scan.
591592
*
592593
* Note we don't worry about the page range at the end of the table here; it is
593594
* present in the build state struct after we're called the last time, but not
@@ -718,8 +719,8 @@ brinbuild(Relation heap, Relation index, IndexInfo *indexInfo)
718719
* Now scan the relation. No syncscan allowed here because we want the
719720
* heap blocks in physical order.
720721
*/
721-
reltuples=IndexBuildHeapScan(heap,index,indexInfo, false,
722-
brinbuildCallback, (void*)state,NULL);
722+
reltuples=table_index_build_scan(heap,index,indexInfo, false,
723+
brinbuildCallback, (void*)state,NULL);
723724

724725
/* process the final batch */
725726
form_and_insert_tuple(state);
@@ -1230,13 +1231,14 @@ summarize_range(IndexInfo *indexInfo, BrinBuildState *state, Relation heapRel,
12301231
* short of brinbuildCallback creating the new index entry.
12311232
*
12321233
* Note that it is critical we use the "any visible" mode of
1233-
* IndexBuildHeapRangeScan here: otherwise, we would miss tuples inserted
1234-
* by transactions that are still in progress, among other corner cases.
1234+
* table_index_build_range_scan here: otherwise, we would miss tuples
1235+
* inserted by transactions that are still in progress, among other corner
1236+
* cases.
12351237
*/
12361238
state->bs_currRangeStart=heapBlk;
1237-
IndexBuildHeapRangeScan(heapRel,state->bs_irel,indexInfo, false, true,
1238-
heapBlk,scanNumBlks,
1239-
brinbuildCallback, (void*)state,NULL);
1239+
table_index_build_range_scan(heapRel,state->bs_irel,indexInfo, false, true,
1240+
heapBlk,scanNumBlks,
1241+
brinbuildCallback, (void*)state,NULL);
12401242

12411243
/*
12421244
* Now we update the values obtained by the scan with the placeholder

‎src/backend/access/gin/gininsert.c

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,7 @@
1717
#include"access/gin_private.h"
1818
#include"access/ginxlog.h"
1919
#include"access/xloginsert.h"
20+
#include"access/tableam.h"
2021
#include"catalog/index.h"
2122
#include"miscadmin.h"
2223
#include"storage/bufmgr.h"
@@ -394,8 +395,9 @@ ginbuild(Relation heap, Relation index, IndexInfo *indexInfo)
394395
* Do the heap scan. We disallow sync scan here because dataPlaceToPage
395396
* prefers to receive tuples in TID order.
396397
*/
397-
reltuples=IndexBuildHeapScan(heap,index,indexInfo, false,
398-
ginBuildCallback, (void*)&buildstate,NULL);
398+
reltuples=table_index_build_scan(heap,index,indexInfo, false,
399+
ginBuildCallback, (void*)&buildstate,
400+
NULL);
399401

400402
/* dump remaining entries to the index */
401403
oldCtx=MemoryContextSwitchTo(buildstate.tmpCtx);

‎src/backend/access/gist/gistbuild.c

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,7 @@
1919
#include"access/genam.h"
2020
#include"access/gist_private.h"
2121
#include"access/gistxlog.h"
22+
#include"access/tableam.h"
2223
#include"access/xloginsert.h"
2324
#include"catalog/index.h"
2425
#include"miscadmin.h"
@@ -204,8 +205,9 @@ gistbuild(Relation heap, Relation index, IndexInfo *indexInfo)
204205
/*
205206
* Do the heap scan.
206207
*/
207-
reltuples=IndexBuildHeapScan(heap,index,indexInfo, true,
208-
gistBuildCallback, (void*)&buildstate,NULL);
208+
reltuples=table_index_build_scan(heap,index,indexInfo, true,
209+
gistBuildCallback,
210+
(void*)&buildstate,NULL);
209211

210212
/*
211213
* If buffering was used, flush out all the tuples that are still in the
@@ -454,7 +456,7 @@ calculatePagesPerBuffer(GISTBuildState *buildstate, int levelStep)
454456
}
455457

456458
/*
457-
* Per-tuple callbackfrom IndexBuildHeapScan.
459+
* Per-tuple callbackfor table_index_build_scan.
458460
*/
459461
staticvoid
460462
gistBuildCallback(Relationindex,

‎src/backend/access/hash/hash.c

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,7 @@
2121
#include"access/hash.h"
2222
#include"access/hash_xlog.h"
2323
#include"access/relscan.h"
24+
#include"access/tableam.h"
2425
#include"catalog/index.h"
2526
#include"commands/vacuum.h"
2627
#include"miscadmin.h"
@@ -159,8 +160,9 @@ hashbuild(Relation heap, Relation index, IndexInfo *indexInfo)
159160
buildstate.heapRel=heap;
160161

161162
/* do the heap scan */
162-
reltuples=IndexBuildHeapScan(heap,index,indexInfo, true,
163-
hashbuildCallback, (void*)&buildstate,NULL);
163+
reltuples=table_index_build_scan(heap,index,indexInfo, true,
164+
hashbuildCallback,
165+
(void*)&buildstate,NULL);
164166

165167
if (buildstate.spool)
166168
{
@@ -190,7 +192,7 @@ hashbuildempty(Relation index)
190192
}
191193

192194
/*
193-
* Per-tuple callbackfrom IndexBuildHeapScan
195+
* Per-tuple callbackfor table_index_build_scan
194196
*/
195197
staticvoid
196198
hashbuildCallback(Relationindex,

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp