Docs: Move parallel_leader_participation GUC description under relevant category

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