sharpetronics/PostgreSQL
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-22 00:02:02 -04:00
Code Issues Projects Releases Wiki Activity

doc: Mention BRIN indexes support parallel builds

Browse Source 
Two places in the documentation suggest B-tree is the only index access
method allowing parallel builds. Commit b4375717 added parallel builds
for BRIN too, but failed to update the docs. So fix that, and backpatch
to 17, where parallel BRIN builds were introduced.

Author: Egor Rogov
Backpatch-through: 17
Discussion: https://postgr.es/m/114e2d5d-125e-07d8-94aa-5ad175fb7443@postgrespro.ru
This commit is contained in:
Tomas Vondra 2024-12-16 19:08:52 +01:00
parent d1253c67fa
commit f5dec4e861
2 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/src/sgml/config.sgml
View File

@ -2810,7 +2810,7 @@ include_dir 'conf.d'
Sets the maximum number of parallel workers that can be
started by a single utility command. Currently, the parallel
utility commands that support the use of parallel workers are
<command>CREATE INDEX</command> only when building a B-tree index,
<command>CREATE INDEX</command> when building a B-tree or BRIN index,
and <command>VACUUM</command> without <literal>FULL</literal>
option. Parallel workers are taken from the pool of processes
established by <xref linkend="guc-max-worker-processes"/>, limited

2
doc/src/sgml/ref/create_index.sgml
View File

@ -808,7 +808,7 @@ Indexes:
leveraging multiple CPUs in order to process the table rows faster.
This feature is known as <firstterm>parallel index
build</firstterm>. For index methods that support building indexes
in parallel (currently, only B-tree),
in parallel (currently, B-tree and BRIN),
<varname>maintenance_work_mem</varname> specifies the maximum
amount of memory that can be used by each index build operation as
a whole, regardless of how many worker processes were started.