be set in the
         <filename>postgresql.conf</filename> file or on the server command
         line.
        </para>
        <para>
         Only has an effect if <xref linkend="guc-io-method"/> is set to
         <literal>worker</literal>.
        </para>
       </listitem>
      </varlistentry>
     </variablelist>
    </sect2>

    <sect2 id="runtime-config-resource-worker-processes">
     <title>Worker Processes</title>

     <variablelist>
      <varlistentry id="guc-max-worker-processes" xreflabel="max_worker_processes">
       <term><varname>max_worker_processes</varname> (<type>integer</type>)
       <indexterm>
        <primary><varname>max_worker_processes</varname> configuration parameter</primary>
       </indexterm>
       </term>
       <listitem>
        <para>
         Sets the maximum number of background processes that the cluster
         can support.  This parameter can only be set at server start.  The
         default is 8.
        </para>

        <para>
         When running a standby server, you must set this parameter to the
         same or higher value than on the primary server. Otherwise, queries
         will not be allowed in the standby server.
        </para>

        <para>
         When changing this value, consider also adjusting
         <xref linkend="guc-max-parallel-workers"/>,
         <xref linkend="guc-max-parallel-maintenance-workers"/>, and
         <xref linkend="guc-max-parallel-workers-per-gather"/>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-max-parallel-workers-per-gather" xreflabel="max_parallel_workers_per_gather">
       <term><varname>max_parallel_workers_per_gather</varname> (<type>integer</type>)
       <indexterm>
        <primary><varname>max_parallel_workers_per_gather</varname> configuration parameter</primary>
       </indexterm>
       </term>
       <listitem>
        <para>
         Sets the maximum number of workers that can be started by a single
         <literal>Gather</literal> or <literal>Gather Merge</literal> node.
         Parallel workers are taken from the pool of processes established by
         <xref linkend="guc-max-worker-processes"/>, limited by
         <xref linkend="guc-max-parallel-workers"/>.  Note that the requested
         number of workers may not actually be available at run time.  If this
         occurs, the plan will run with fewer workers than expected, which may
         be inefficient.  The default value is 2.  Setting this value to 0
         disables parallel query execution.
        </para>

        <para>
         Note that parallel queries may consume very substantially more
         resources than non-parallel queries, because each worker process is
         a completely separate process which has roughly the same impact on the
         system as an additional user session.  This should be taken into
         account when choosing a value for this setting, as well as when
         configuring other settings that control resource utilization, such
         as <xref linkend="guc-work-mem"/>.  Resource limits such as
         <varname>work_mem</varname> are applied individually to each worker,
         which means the total utilization may be much higher across all
         processes than it would normally be for any single process.
         For example, a parallel query using 4 workers may use up to 5 times
         as much CPU time, memory, I/O bandwidth, and so forth as a query which
         uses no workers at all.
        </para>

        <para>
         For more information on parallel query, see
         <xref linkend="parallel-query"/>.
        </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>
        <primary><varname>max_parallel_maintenance_workers</varname> configuration