zero), there may be some reason why the query planner is
    unable to generate a parallel plan for your query.  See
    <xref linkend="when-can-parallel-query-be-used"/> and
    <xref linkend="parallel-safety"/> for information on why this may be
    the case.
  </para>

  <para>
    When executing a parallel plan, you can use <literal>EXPLAIN (ANALYZE,
    VERBOSE)</literal> to display per-worker statistics for each plan node.
    This may be useful in determining whether the work is being evenly
    distributed between all plan nodes and more generally in understanding the
    performance characteristics of the plan.
  </para>

 </sect2>
 </sect1>

 <sect1 id="parallel-safety">
  <title>Parallel Safety</title>

  <para>
    The planner classifies operations involved in a query as either
    <firstterm>parallel safe</firstterm>, <firstterm>parallel restricted</firstterm>,
    or <firstterm>parallel unsafe</firstterm>.  A parallel safe operation is one that
    does not conflict with the use of parallel query.  A parallel restricted
    operation is one that cannot be performed in a parallel worker, but that
    can be performed in the leader while parallel query is in use.  Therefore,
    parallel restricted operations can never occur below a <literal>Gather</literal>
    or <literal>Gather Merge</literal> node, but can occur elsewhere in a plan that
    contains such a node.  A parallel unsafe operation is one that cannot
    be performed while parallel query is in use, not even in the leader.
    When a query contains anything that is parallel unsafe, parallel query
    is completely disabled for that query.
  </para>

  <para>
    The following operations are always parallel restricted:
  </para>

  <itemizedlist>
    <listitem>
      <para>
        Scans of common table expressions (CTEs).
      </para>
    </listitem>

    <listitem>
      <para>
        Scans of temporary tables.
      </para>
    </listitem>

    <listitem>
      <para>
        Scans of foreign tables, unless the foreign data wrapper has
        an <literal>IsForeignScanParallelSafe</literal> API that indicates otherwise.
      </para>
    </listitem>

    <listitem>
      <para>
        Plan nodes that reference a correlated <literal>SubPlan</literal>.
      </para>
    </listitem>
  </itemizedlist>

 <sect2 id="parallel-labeling">
  <title>Parallel Labeling for Functions and Aggregates</title>

  <para>
    The planner cannot automatically determine whether a user-defined
    function or aggregate is parallel safe, parallel restricted, or parallel
    unsafe, because this would require predicting every operation that the
    function could possibly perform.  In general, this is equivalent to the
    Halting Problem and therefore impossible.  Even for simple functions
    where it could conceivably be done, we do not try, since this would be expensive
    and error-prone.  Instead, all user-defined functions are assumed to
    be parallel unsafe unless otherwise marked.  When using
    <xref linkend="sql-createfunction"/>