Hi,
It looks like even though the commit e5253fdc4f that added the
parallel_leader_participation GUC correctly categorized it as
RESOURCES_ASYNCHRONOUS parameter in the code, but in the docs it is kept
under irrelevant section i.e. "Query Planning/Other Planner Options". This
is reported in the bugs list [1], cc-ed the reporter.
Attaching a small patch that moves the GUC description to the right place.
Thoughts?
[1]
https://www.postgresql.org/message-id/16972-42d4b0c15aa1d5f5%40postgresql.org
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
From a26f043368173c1b690ed0d170f2d6286ba9f898 Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <bharath.rupireddy@enterprisedb.com>
Date: Tue, 20 Apr 2021 13:32:02 +0530
Subject: [PATCH v1] Move parallel_leader_participation to Resource Consumption
Category
parallel_leader_partiticipation GUC is rightly categorized as
Resource Usage/Asynchronous Behavior parameter in the code, but in
the docs, it is still under Query Planning/Other Planner Options
category. Just move it to the correct place i.e. under Resource
Consumption/Asynchronous Behaviour.
---
doc/src/sgml/config.sgml | 46 ++++++++++++++++++++--------------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 776ab1a8c8..a4dcee1fc8 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2520,6 +2520,29 @@ include_dir 'conf.d'
</listitem>
</varlistentry>
+ <varlistentry id="guc-parallel-leader-participation" xreflabel="parallel_leader_participation">
+ <term>
+ <varname>parallel_leader_participation</varname> (<type>boolean</type>)
+ <indexterm>
+ <primary><varname>parallel_leader_participation</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Allows the leader process to execute the query plan under
+ <literal>Gather</literal> and <literal>Gather Merge</literal> nodes
+ instead of waiting for worker processes. The default is
+ <literal>on</literal>. Setting this value to <literal>off</literal>
+ reduces the likelihood that workers will become blocked because the
+ leader is not reading tuples fast enough, but requires the leader
+ process to wait for worker processes to start up before the first
+ tuples can be produced. The degree to which the leader can help or
+ hinder performance depends on the plan type, number of workers and
+ query duration.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-max-parallel-maintenance-workers" xreflabel="max_parallel_maintenance_workers">
<term><varname>max_parallel_maintenance_workers</varname> (<type>integer</type>)
<indexterm>
@@ -5889,29 +5912,6 @@ SELECT * FROM parent WHERE key = 2400;
</listitem>
</varlistentry>
- <varlistentry id="guc-parallel-leader-participation" xreflabel="parallel_leader_participation">
- <term>
- <varname>parallel_leader_participation</varname> (<type>boolean</type>)
- <indexterm>
- <primary><varname>parallel_leader_participation</varname> configuration parameter</primary>
- </indexterm>
- </term>
- <listitem>
- <para>
- Allows the leader process to execute the query plan under
- <literal>Gather</literal> and <literal>Gather Merge</literal> nodes
- instead of waiting for worker processes. The default is
- <literal>on</literal>. Setting this value to <literal>off</literal>
- reduces the likelihood that workers will become blocked because the
- leader is not reading tuples fast enough, but requires the leader
- process to wait for worker processes to start up before the first
- tuples can be produced. The degree to which the leader can help or
- hinder performance depends on the plan type, number of workers and
- query duration.
- </para>
- </listitem>
- </varlistentry>
-
<varlistentry id="guc-plan-cache_mode" xreflabel="plan_cache_mode">
<term><varname>plan_cache_mode</varname> (<type>enum</type>)
<indexterm>
--
2.25.1
