<listitem>
        <para>
         Sets the maximum number of workers that the cluster can support for
         parallel operations.  The default value is 8.  When increasing or
         decreasing this value, consider also adjusting
         <xref linkend="guc-max-parallel-maintenance-workers"/> and
         <xref linkend="guc-max-parallel-workers-per-gather"/>.
         Also, note that a setting for this value which is higher than
         <xref linkend="guc-max-worker-processes"/> will have no effect,
         since parallel workers are taken from the pool of worker processes
         established by that setting.
        </para>
       </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>
     </variablelist>
    </sect2>
   </sect1>

   <sect1 id="runtime-config-wal">
    <title>Write Ahead Log</title>

   <para>
    For additional information on tuning these settings,
    see <xref linkend="wal-configuration"/>.
   </para>

    <sect2 id="runtime-config-wal-settings">
     <title>Settings</title>
     <variablelist>

     <varlistentry id="guc-wal-level" xreflabel="wal_level">
      <term><varname>wal_level</varname> (<type>enum</type>)
      <indexterm>
       <primary><varname>wal_level</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        <varname>wal_level</varname> determines how much information is written to
        the WAL. The default value is <literal>replica</literal>, which writes enough
        data to support WAL archiving and replication, including running
        read-only queries on a standby server. <literal>minimal</literal> removes all
        logging except the information required to recover from a crash or
        immediate shutdown.  Finally,
        <literal>logical</literal> adds information necessary to support logical
        decoding.  Each level includes the information logged at all lower
        levels.  This parameter can only be set at server start.
       </para>
       <para>
        The <literal>minimal</literal> level generates the least WAL
        volume.  It logs no row information for permanent relations
        in transactions that create or
        rewrite them.  This can make operations much faster (see
        <xref linkend="populate-pitr"/>).  Operations that initiate this
        optimization include:
        <simplelist>
         <member><command>ALTER ... SET TABLESPACE</command></member>
         <member><command>CLUSTER</command></member>
         <member><command>CREATE TABLE</command></member>
         <member><command>REFRESH MATERIALIZED VIEW</command>
         (without <option>CONCURRENTLY</option>)</member>
         <member><command>REINDEX</command></member>
         <member><command>TRUNCATE</command></member>
        </simplelist>
        However, minimal WAL does not contain sufficient information for