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