Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit b437571

Browse files
tvondratvondra
committed
Allow parallel CREATE INDEX for BRIN indexes
Allow using multiple worker processes to build BRIN index, which until now was supported only for BTREE indexes. For large tables this often results in significant speedup when the build is CPU-bound. The work is split in a simple way - each worker builds BRIN summaries on a subset of the table, determined by the regular parallel scan used to read the data, and feeds them into a shared tuplesort which sorts them by blkno (start of the range). The leader then reads this sorted stream of ranges, merges duplicates (which may happen if the parallel scan does not align with BRIN pages_per_range), and adds the resulting ranges into the index. The number of duplicate results produced by workers (requiring merging in the leader process) should be fairly small, thanks to how parallel scans assign chunks to workers. The likelihood of duplicate results may increase for higher pages_per_range values, but then there are fewer page ranges in total. In any case, we expect the merging to be much cheaper than summarization, so this should be a win. Most of the parallelism infrastructure is a simplified copy of the code used by BTREE indexes, omitting the parts irrelevant for BRIN indexes (e.g. uniqueness checks). This also introduces a new index AM flag amcanbuildparallel, determining whether to attempt to start parallel workers for the index build. Original patch by me, with reviews and substantial reworks by Matthias van de Meent, certainly enough to make him a co-author. Author: Tomas Vondra, Matthias van de Meent Reviewed-by: Matthias van de Meent Discussion: https://postgr.es/m/c2ee7d69-ce17-43f2-d1a0-9811edbda6e6%40enterprisedb.com
1 parent dae761a commit b437571

File tree

16 files changed

+1118
-16
lines changed

16 files changed

+1118
-16
lines changed

‎contrib/bloom/blutils.c

+1
Original file line numberDiff line numberDiff line change
@@ -122,6 +122,7 @@ blhandler(PG_FUNCTION_ARGS)
122122
amroutine->amclusterable = false;
123123
amroutine->ampredlocks = false;
124124
amroutine->amcanparallel = false;
125+
amroutine->amcanbuildparallel = false;
125126
amroutine->amcaninclude = false;
126127
amroutine->amusemaintenanceworkmem = false;
127128
amroutine->amparallelvacuumoptions =

‎doc/src/sgml/indexam.sgml

+7
Original file line numberDiff line numberDiff line change
@@ -123,6 +123,8 @@ typedef struct IndexAmRoutine
123123
bool ampredlocks;
124124
/* does AM support parallel scan? */
125125
bool amcanparallel;
126+
/* does AM support parallel build? */
127+
bool amcanbuildparallel;
126128
/* does AM support columns included with clause INCLUDE? */
127129
bool amcaninclude;
128130
/* does AM use maintenance_work_mem? */
@@ -286,6 +288,11 @@ ambuild (Relation heapRelation,
286288
and compute the keys that need to be inserted into the index.
287289
The function must return a palloc'd struct containing statistics about
288290
the new index.
291+
The <structfield>amcanbuildparallel</structfield> flag indicates whether
292+
the access method supports parallel index builds. When set to <literal>true</literal>,
293+
the system will attempt to allocate parallel workers for the build.
294+
Access methods supporting only non-parallel index builds should leave
295+
this flag set to <literal>false</literal>.
289296
</para>
290297

291298
<para>

0 commit comments

Comments
 (0)