Re: Parallel index build for BRIN

Hi everyone,

Thisthread doesn'tseem to have attractedattention, so let me try again. 
Two documentation pages claim that B-tree is the only access method that 
supports parallel building, which is no longer true. I propose to fix it 
in a way like this:

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index d54f9049569..b5b1580dee7 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2835,7 +2835,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
diff --git a/doc/src/sgml/ref/create_index.sgml 
b/doc/src/sgml/ref/create_index.sgml
index 621bc0e253c..208389e8006 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -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.

Thanks,
Egor


On 05.11.2024 12:12, Egor Rogov wrote:
> Hi,
>
> Commit b4375717 introduced parallel CREATE INDEX for BRIN. I've 
> noticed that a couple of documentation pages need to be updated 
> accordingly. A small patch is attached.
>
> Thanks,
> Egor