Mention GIN indexes support parallel builds.
Hi, Commit 8492feb98f6 added support for parallel CREATE INDEX on GIN indexes. However, there are still two places in the docs and two in the source code comments that mention only B-tree and BRIN as supporting parallel builds. These references should be updated to include GIN indexes as well. Patch attached. Regards, -- Fujii Masao NTT DATA Japan Corporation From 649b27e536194589c2bf85a05cb84e731dbfeac0 Mon Sep 17 00:00:00 2001 From: Fujii Masao Date: Wed, 18 Jun 2025 16:30:36 +0900 Subject: [PATCH v1] doc: Mention GIN indexes support parallel builds. Commit 8492feb98f6 added support for parallel CREATE INDEX on GIN indexes. However, previously two places in the documentation and two in the source code comments still stated that only B-tree and BRIN indexes support parallel builds. This commit updates those references to correctly include GIN indexes. --- doc/src/sgml/config.sgml | 3 ++- doc/src/sgml/ref/create_index.sgml | 2 +- src/backend/catalog/index.c | 2 +- src/backend/optimizer/plan/planner.c | 2 +- 4 files changed, 5 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 7e0e5400ee1..7ee9ea4191e 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2894,7 +2894,8 @@ 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 - CREATE INDEX when building a B-tree or BRIN index, + CREATE INDEX when building a B-tree, + GIN, or BRIN index, and VACUUM without FULL option. Parallel workers are taken from the pool of processes established by , limited diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml index 147a8f7587c..b9c679c41e8 100644 --- a/doc/src/sgml/ref/create_index.sgml +++ b/doc/src/sgml/ref/create_index.sgml @@ -814,7 +814,7 @@ Indexes: leveraging multiple CPUs in order to process the table rows faster. This feature is known as parallel index build. For index methods that support building indexes - in parallel (currently, B-tree and BRIN), + in parallel (currently, B-tree, GIN, and BRIN), maintenance_work_mem 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. diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c index 739a92bdcc1..aa216683b74 100644 --- a/src/backend/catalog/index.c +++ b/src/backend/catalog/index.c @@ -3020,7 +3020,7 @@ index_build(Relation heapRelation, /* * Determine worker process details for parallel CREATE INDEX. Currently, -* only btree and BRIN have support for parallel builds. +* only btree, GIN, and BRIN have support for parallel builds. * * Note that planner considers parallel safety for us. */ diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c index ff65867eebe..549aedcfa99 100644 --- a/src/backend/optimizer/plan/planner.c +++ b/src/backend/optimizer/plan/planner.c @@ -6879,7 +6879,7 @@ plan_cluster_use_sort(Oid tableOid, Oid indexOid) * * tableOid is the table on which the index is to be built. indexOid is the * OID of an index to be created or reindexed (which must be an index with - * support for parallel builds - currently btree or BRIN). + * support for parallel builds - currently btree, GIN, or BRIN). * * Return value is the number of parallel worker processes to request. It * may be unsafe to proceed if this is 0. Note that this does not include the -- 2.49.0
Re: Fix inaccurate mention of index comments in CREATE FOREIGN TABLE docs
On 2025/06/18 15:50, Michael Paquier wrote: On Wed, Jun 18, 2025 at 02:34:55PM +0900, Fujii Masao wrote: Commit 302cf157592 added support for LIKE in CREATE FOREIGN TABLE. In this feature, since indexes are not created for foreign tables, comments on indexes are not copied either. Good point. This doc fix sounds fine to me. Thanks for the review! I will commit the patch barring any other objections. Regards, -- Fujii Masao NTT DATA Japan Corporation
Deprecated openssl command option in documentation
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/17/ssl-tcp.html Description: Hi In the documentation at https://www.postgresql.org/docs/17/ssl-tcp.html, it says, in 18.9.5. Creating Certificates: ``` To create a simple self-signed certificate for the server, valid for 365 days, use the following OpenSSL command, replacing dbhost.yourdomain.com with the server's host name: openssl req -new -x509 -days 365 -nodes -text -out server.crt \ -keyout server.key -subj "/CN=dbhost.yourdomain.com" ``` However, on Ubuntu, running "openssl req --help" shows the following: ``` Output options: ... -noencDon't encrypt private keys -nodesDon't encrypt private keys; deprecated ``` Therefore, I suggest you replace the "-nodes" switch in the command example to "-noenc". Ubuntu version: ``` $ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.5 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.5 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; UBUNTU_CODENAME=jammy ```
Re: Deprecated openssl command option in documentation
> On 18 Jun 2025, at 13:24, PG Doc comments form wrote: > -noencDon't encrypt private keys > -nodesDon't encrypt private keys; deprecated > ``` > Therefore, I suggest you replace the "-nodes" switch in the command example > to "-noenc". Thanks for your report! The noenc option, and subsequent deprecation notice on nodes, came in OpenSSL 3.0 but PostgreSQL still support OpenSSL 1.1.1. nodes is still available in the recent 3.5 version so sticking with it is the safe option for us (until we deprecate 1.1.1 support, which is a fair bit into the future). -- Daniel Gustafsson
Re: Fix inaccurate mention of index comments in CREATE FOREIGN TABLE docs
On 2025/06/18 16:55, Fujii Masao wrote: On 2025/06/18 15:50, Michael Paquier wrote: On Wed, Jun 18, 2025 at 02:34:55PM +0900, Fujii Masao wrote: Commit 302cf157592 added support for LIKE in CREATE FOREIGN TABLE. In this feature, since indexes are not created for foreign tables, comments on indexes are not copied either. Good point. This doc fix sounds fine to me. Thanks for the review! I will commit the patch barring any other objections. I've pushed the patch. Thanks! Regards, -- Fujii Masao NTT DATA Japan Corporation
Re: Mention GIN indexes support parallel builds.
On 2025/06/19 4:50, Robert Treat wrote: On Wed, Jun 18, 2025 at 3:55 AM Fujii Masao wrote: Hi, Commit 8492feb98f6 added support for parallel CREATE INDEX on GIN indexes. However, there are still two places in the docs and two in the source code comments that mention only B-tree and BRIN as supporting parallel builds. These references should be updated to include GIN indexes as well. Patch attached. Makes sense, +1 from me. Thanks for the review! I've pushed the patch. Regards, -- Fujii Masao NTT DATA Japan Corporation
Re: Document if width_bucket's low and high are inclusive/exclusive
On Fri, Feb 28, 2025 at 7:15 AM Ben Peachey Higdon wrote: > The current documentation for width_bucket > (https://www.postgresql.org/docs/current/functions-math.html) does not > mention if the range’s low and high are inclusive or exclusive. > > Returns the number of the bucket in which operand falls in a histogram having > count equal-width buckets spanning the range low to high. Returns 0 or > count+1 for an input outside that range. > > I had assumed that both the low and high were inclusive but actually the low > is inclusive while the high is exclusive. > I'm not sure it's the most ground breaking thing, but would probably save a bunch of future people from having to gin up an example to test it, so I'd probably update it per the following patch. Robert Treat https://xzilla.net v1-0001-Document-width_bucket-range-as-inclusive-exclusiv.patch Description: Binary data
Re: Mention GIN indexes support parallel builds.
On Wed, Jun 18, 2025 at 3:55 AM Fujii Masao wrote: > > Hi, > > Commit 8492feb98f6 added support for parallel CREATE INDEX on GIN indexes. > However, there are still two places in the docs and two in the source code > comments that mention only B-tree and BRIN as supporting parallel builds. > > These references should be updated to include GIN indexes as well. Patch > attached. > Makes sense, +1 from me. Robert Treat https://xzilla.net
Re: Document if width_bucket's low and high are inclusive/exclusive
Robert Treat writes: > On Fri, Feb 28, 2025 at 7:15 AM Ben Peachey Higdon > wrote: >> The current documentation for width_bucket >> (https://www.postgresql.org/docs/current/functions-math.html) does not >> mention if the range’s low and high are inclusive or exclusive. > I'm not sure it's the most ground breaking thing, but would probably > save a bunch of future people from having to gin up an example to test > it, so I'd probably update it per the following patch. Seems reasonable, but do we need to do anything with the other version of width_bucket (the one taking an array of lower bounds)? Perhaps this change provides enough context, but I'm unsure. regards, tom lane
Re: Document if width_bucket's low and high are inclusive/exclusive
On Wed, Jun 18, 2025 at 4:12 PM Tom Lane wrote: > Robert Treat writes: > > On Fri, Feb 28, 2025 at 7:15 AM Ben Peachey Higdon > > wrote: > >> The current documentation for width_bucket > >> (https://www.postgresql.org/docs/current/functions-math.html) does not > >> mention if the range’s low and high are inclusive or exclusive. > > > I'm not sure it's the most ground breaking thing, but would probably > > save a bunch of future people from having to gin up an example to test > > it, so I'd probably update it per the following patch. > > Seems reasonable, but do we need to do anything with the other > version of width_bucket (the one taking an array of lower bounds)? > Perhaps this change provides enough context, but I'm unsure. > Since they are all lower bounds, they all operate the same way, so it isn't quite as clear that it needs documenting. Are you thinking something like this? Returns the number of the bucket in which operand falls given an array listing the lower bounds (inclusive) of the buckets Robert Treat https://xzilla.net
Re: Fix inaccurate mention of index comments in CREATE FOREIGN TABLE docs
On Wed, Jun 18, 2025 at 04:55:56PM +0900, Fujii Masao wrote: > Thanks for the review! I will commit the patch barring any other objections. Thanks. -- Michael signature.asc Description: PGP signature
