Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1tKiuA-00AQ7o-Up
	for pgsql-docs@arkaria.postgresql.org; Mon, 09 Dec 2024 18:54:50 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1tKiu8-00Atav-Ea
	for pgsql-docs@arkaria.postgresql.org; Mon, 09 Dec 2024 18:54:49 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <tomas@vondra.me>)
	id 1tKiu8-00Atan-6Z
	for pgsql-docs@lists.postgresql.org; Mon, 09 Dec 2024 18:54:49 +0000
Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229])
	by magus.postgresql.org with esmtps  (TLS1.2) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <tomas@vondra.me>)
	id 1tKiu6-001vut-Ef
	for pgsql-docs@lists.postgresql.org; Mon, 09 Dec 2024 18:54:48 +0000
Received: by mail.gandi.net (Postfix) with ESMTPSA id 480B6FF803;
	Mon,  9 Dec 2024 18:54:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vondra.me; s=gm1;
	t=1733770484;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=+TtrvPZlTMySkPohGjRwGWBQsDX0eHP+lLo5VCPFTG4=;
	b=E86BsV3DAMD6MdwVH3o9PNnObLdl/gP/XeetN9oJYTNWJbMHL07SMVSU8mJEKM6/QHhOpK
	8dNI2+Se3ERhY1Sv+l6LVJbyghYjVYkKgTb/+xzcXvgxh0PvMMysWVkp9yOmpLINwgsoSo
	ZMTPAtu4uhdoKqk5xgD/M4kvMviS20kyeOnptloSlSnXK3IX2gmAviKOVVXn411/5/WoR8
	yE5RUDFaib2Yusagl9+H976uFgXRqDOSLvqyzFhnI90Q6zSyE3elSfpj/sSsSQXjOxzcJm
	NwsXj0JdGETvJMpgiexgJ+A6oLzt5rs4Qg3aIBqlnh6ot63mkXFQTf3ZcrpMHw==
Message-ID: <733bf5ec-2bb9-4e51-805d-b5e33a37609c@vondra.me>
Date: Mon, 9 Dec 2024 19:54:42 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Parallel index build for BRIN
To: Egor Rogov <e.rogov@postgrespro.ru>, pgsql-docs@lists.postgresql.org
References: <114e2d5d-125e-07d8-94aa-5ad175fb7443@postgrespro.ru>
 <009f4101-29a2-850e-6767-72a9104ec89a@postgrespro.ru>
 <908b63e1-4b79-2889-98d1-1909cac39785@postgrespro.ru>
Content-Language: en-US
From: Tomas Vondra <tomas@vondra.me>
In-Reply-To: <908b63e1-4b79-2889-98d1-1909cac39785@postgrespro.ru>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-GND-Sasl: tomas@vondra.me
List-Id: <pgsql-docs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-docs@lists.postgresql.org>
List-Owner: <mailto:pgsql-docs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-docs>
Archived-At: 
 <https://www.postgresql.org/message-id/733bf5ec-2bb9-4e51-805d-b5e33a37609c%40vondra.me>
Precedence: bulk

On 12/8/24 16:00, Egor Rogov wrote:
> Hi,
> 
> 
> On 17.11.2024 11:28, Egor Rogov wrote:
>> Hi everyone,
>>
>> This thread doesn't seem to have attracted attention, 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.
> 
> 
> I've spotted another mention of B-tree being the only AM that supports
> parallel builds: comment in src/backend/catalog/index.c. As this mention
> is not visible to the users, I'd propose removing it altogether rather
> than fixing it. Updated patch is attached.
> 

Thanks for noticing this and the patches. You're right, this should have
been updated with the BRIN parallel builds. I'll get this committed
sometime the week.


regards

-- 
Tomas Vondra