doc: Move parallel_leader_participation to its correct category

parallel_leader_participation got introduced in e5253fd, where it was
listed under RESOURCES_ASYNCHRONOUS in guc.c, but the documentation
did not reflect that and listed it with the other planner-related
options.  This commit fixes this inconsistency as the parameter is
intended to be an asynchronous one.

While on it, reorganize a bit the section dedicated to asynchronous
parameters, backend_flush_after being moved first to do better in terms
of alphabetical order of the options listed.

Reported-by: Yanliang Lei
Author: Bharath Rupireddy
Discussion: https://postgr.es/m/16972-42d4b0c15aa1d5f5@postgresql.org

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index dd7ebe7a9dad28a53fadf255894caa4bf5de3f05..cf75d913ce97d624f5aeb0bca7f6479164eee793 100644 (file)
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2383,6 +2383,36 @@ include_dir 'conf.d'
      <title>Asynchronous Behavior</title>
 
      <variablelist>
+      <varlistentry id="guc-backend-flush-after" xreflabel="backend_flush_after">
+       <term><varname>backend_flush_after</varname> (<type>integer</type>)
+       <indexterm>
+        <primary><varname>backend_flush_after</varname> configuration parameter</primary>
+       </indexterm>
+       </term>
+       <listitem>
+        <para>
+         Whenever more than this amount of data has
+         been written by a single backend, attempt to force the OS to issue
+         these writes to the underlying storage.  Doing so will limit the
+         amount of dirty data in the kernel's page cache, reducing the
+         likelihood of stalls when an <function>fsync</function> is issued at the end of a
+         checkpoint, or when the OS writes data back in larger batches in the
+         background.  Often that will result in greatly reduced transaction
+         latency, but there also are some cases, especially with workloads
+         that are bigger than <xref linkend="guc-shared-buffers"/>, but smaller
+         than the OS's page cache, where performance might degrade.  This
+         setting may have no effect on some platforms.
+         If this value is specified without units, it is taken as blocks,
+         that is <symbol>BLCKSZ</symbol> bytes, typically 8kB.
+         The valid range is
+         between <literal>0</literal>, which disables forced writeback,
+         and <literal>2MB</literal>.  The default is <literal>0</literal>, i.e., no
+         forced writeback.  (If <symbol>BLCKSZ</symbol> is not 8kB,
+         the maximum value scales proportionally to it.)
+        </para>
+       </listitem>
+      </varlistentry>
+
       <varlistentry id="guc-effective-io-concurrency" xreflabel="effective_io_concurrency">
        <term><varname>effective_io_concurrency</varname> (<type>integer</type>)
        <indexterm>
@@ -2579,32 +2609,25 @@ include_dir 'conf.d'
        </listitem>
       </varlistentry>
 
-      <varlistentry id="guc-backend-flush-after" xreflabel="backend_flush_after">
-       <term><varname>backend_flush_after</varname> (<type>integer</type>)
+      <varlistentry id="guc-parallel-leader-participation" xreflabel="parallel_leader_participation">
+       <term>
+       <varname>parallel_leader_participation</varname> (<type>boolean</type>)
        <indexterm>
-        <primary><varname>backend_flush_after</varname> configuration parameter</primary>
+        <primary><varname>parallel_leader_participation</varname> configuration parameter</primary>
        </indexterm>
        </term>
        <listitem>
         <para>
-         Whenever more than this amount of data has
-         been written by a single backend, attempt to force the OS to issue
-         these writes to the underlying storage.  Doing so will limit the
-         amount of dirty data in the kernel's page cache, reducing the
-         likelihood of stalls when an <function>fsync</function> is issued at the end of a
-         checkpoint, or when the OS writes data back in larger batches in the
-         background.  Often that will result in greatly reduced transaction
-         latency, but there also are some cases, especially with workloads
-         that are bigger than <xref linkend="guc-shared-buffers"/>, but smaller
-         than the OS's page cache, where performance might degrade.  This
-         setting may have no effect on some platforms.
-         If this value is specified without units, it is taken as blocks,
-         that is <symbol>BLCKSZ</symbol> bytes, typically 8kB.
-         The valid range is
-         between <literal>0</literal>, which disables forced writeback,
-         and <literal>2MB</literal>.  The default is <literal>0</literal>, i.e., no
-         forced writeback.  (If <symbol>BLCKSZ</symbol> is not 8kB,
-         the maximum value scales proportionally to it.)
+         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>
@@ -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>