diff options
| author | Tomas Vondra <tomas.vondra@postgresql.org> | 2023-12-08 18:15:23 +0100 |
|---|---|---|
| committer | Tomas Vondra <tomas.vondra@postgresql.org> | 2023-12-08 18:15:26 +0100 |
| commit | b437571714707bc6466abde1a0af5e69aaade09c (patch) | |
| tree | 0419c054a18274366fe9ac009a6085126f96dd0b /doc/src | |
| parent | dae761a87edae444d11a411f711f1d679bed5941 (diff) | |
| download | postgresql-b437571714707bc6466abde1a0af5e69aaade09c.tar.gz postgresql-b437571714707bc6466abde1a0af5e69aaade09c.zip | |
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
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/indexam.sgml | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/doc/src/sgml/indexam.sgml b/doc/src/sgml/indexam.sgml index f107c43d6a6..cc4135e3940 100644 --- a/doc/src/sgml/indexam.sgml +++ b/doc/src/sgml/indexam.sgml @@ -123,6 +123,8 @@ typedef struct IndexAmRoutine bool ampredlocks; /* does AM support parallel scan? */ bool amcanparallel; + /* does AM support parallel build? */ + bool amcanbuildparallel; /* does AM support columns included with clause INCLUDE? */ bool amcaninclude; /* does AM use maintenance_work_mem? */ @@ -286,6 +288,11 @@ ambuild (Relation heapRelation, and compute the keys that need to be inserted into the index. The function must return a palloc'd struct containing statistics about the new index. + The <structfield>amcanbuildparallel</structfield> flag indicates whether + the access method supports parallel index builds. When set to <literal>true</literal>, + the system will attempt to allocate parallel workers for the build. + Access methods supporting only non-parallel index builds should leave + this flag set to <literal>false</literal>. </para> <para> |