nodes to perform these operations.  Again,
    there is usually more than one possible way to do these operations,
    so different node types can appear here too.  The output
    of <command>EXPLAIN</command> has one line for each node in the plan
    tree, showing the basic node type plus the cost estimates that the planner
    made for the execution of that plan node.  Additional lines might appear,
    indented from the node's summary line,
    to show additional properties of the node.
    The very first line (the summary line for the topmost
    node) has the estimated total execution cost for the plan; it is this
    number that the planner seeks to minimize.
   </para>

   <para>
    Here is a trivial example, just to show what the output looks like:

<screen>
EXPLAIN SELECT * FROM tenk1;

                         QUERY PLAN
-------------------------------------------------------------
 Seq Scan on tenk1  (cost=0.00..445.00 rows=10000 width=244)
</screen>
   </para>

   <para>
    Since this query has no <literal>WHERE</literal> clause, it must scan all the
    rows of the table, so the planner has chosen to use a simple sequential
    scan plan.  The numbers that are quoted in parentheses are (left
    to right):

    <itemizedlist>
     <listitem>
      <para>
       Estimated start-up cost.  This is the time expended before the output
       phase can begin, e.g., time to do the sorting in a sort node.
      </para>
     </listitem>

     <listitem>
      <para>
       Estimated total cost.  This is stated on the assumption that the plan
       node is run to completion, i.e., all available rows are retrieved.
       In practice a node's parent node might stop short of reading all
       available rows (see the <literal>LIMIT</literal> example below).
      </para>
     </listitem>

     <listitem>
      <para>
       Estimated number of rows output by this plan node.  Again, the node
       is assumed to be run to completion.
      </para>
     </listitem>

     <listitem>
      <para>
       Estimated average width of rows output by this plan node (in bytes).
      </para>
     </listitem>
    </itemizedlist>
   </para>

   <para>
    The costs are measured in arbitrary units determined by the planner's
    cost parameters (see <xref linkend="runtime-config-query-constants"/>).
    Traditional practice is to measure the costs in units of disk page
    fetches; that is, <xref linkend="guc-seq-page-cost"/> is conventionally
    set to <literal>1.0</literal> and the other cost parameters are set relative
    to that.  The examples in this section are run with the default cost
    parameters.
   </para>

   <para>
    It's important to understand that the cost of an upper-level node includes
    the cost of all its child nodes.  It's also important to realize that
    the cost only reflects things that the planner cares about.
    In particular, the cost does not consider the time spent to convert
    output values to text form or to transmit them to the client, which
    could be important factors in the real elapsed time; but the planner
    ignores those costs because it cannot change them by altering the
    plan.  (Every correct plan will output the same row set, we trust.)
   </para>

   <para>
    The <literal>rows</literal> value is a little tricky because it is
    not the number of rows processed or scanned by the
    plan node, but rather the number emitted by the node.  This is often
    less than the number scanned, as a result of filtering by any
    <literal>WHERE</literal>-clause conditions that are being applied at the node.
    Ideally the top-level rows estimate will approximate the number of rows
    actually returned, updated, or deleted by the query.
   </para>

   <para>
    Returning to our example:

<screen>
EXPLAIN SELECT * FROM tenk1;

                         QUERY PLAN
-------------------------------------------------------------
 Seq Scan on tenk1  (cost=0.00..445.00 rows=10000 width=244)