(cost=0.00..0.02 rows=1 width=4)
           Output: ((random() * '10'::double precision))::integer
</screen>

    An initplan is run only once per execution of the outer plan, and its
    results are saved for re-use in later rows of the outer plan.  So in
    this example <literal>random()</literal> is evaluated only once and
    all the values of <literal>t1.ten</literal> are compared to the same
    randomly-chosen integer.  That's quite different from what would
    happen without the sub-<literal>SELECT</literal> construct.
   </para>

  </sect2>

  <sect2 id="using-explain-analyze">
   <title><command>EXPLAIN ANALYZE</command></title>

   <para>
    It is possible to check the accuracy of the planner's estimates
    by using <command>EXPLAIN</command>'s <literal>ANALYZE</literal> option.  With this
    option, <command>EXPLAIN</command> actually executes the query, and then displays
    the true row counts and true run time accumulated within each plan node,
    along with the same estimates that a plain <command>EXPLAIN</command>
    shows.  For example, we might get a result like this:

<screen>
EXPLAIN ANALYZE SELECT *
FROM tenk1 t1, tenk2 t2
WHERE t1.unique1 &lt; 10 AND t1.unique2 = t2.unique2;

                                                           QUERY PLAN
-------------------------------------------------------------------&zwsp;--------------------------------------------------------------
 Nested Loop  (cost=4.65..118.50 rows=10 width=488) (actual time=0.017..0.051 rows=10.00 loops=1)
   Buffers: shared hit=36 read=6
   -&gt;  Bitmap Heap Scan on tenk1 t1  (cost=4.36..39.38 rows=10 width=244) (actual time=0.009..0.017 rows=10.00 loops=1)
         Recheck Cond: (unique1 &lt; 10)
         Heap Blocks: exact=10
         Buffers: shared hit=3 read=5 written=4
         -&gt;  Bitmap Index Scan on tenk1_unique1  (cost=0.00..4.36 rows=10 width=0) (actual time=0.004..0.004 rows=10.00 loops=1)
               Index Cond: (unique1 &lt; 10)
               Index Searches: 1
               Buffers: shared hit=2
   -&gt;  Index Scan using tenk2_unique2 on tenk2 t2  (cost=0.29..7.90 rows=1 width=244) (actual time=0.003..0.003 rows=1.00 loops=10)
         Index Cond: (unique2 = t1.unique2)
         Index Searches: 10
         Buffers: shared hit=24 read=6
 Planning:
   Buffers: shared hit=15 dirtied=9
 Planning Time: 0.485 ms
 Execution Time: 0.073 ms
</screen>

    Note that the <quote>actual time</quote> values are in milliseconds of
    real time, whereas the <literal>cost</literal> estimates are expressed in
    arbitrary units; so they are unlikely to match up.
    The thing that's usually most important to look for is whether the
    estimated row counts are reasonably close to reality.  In this example
    the estimates were all dead-on, but that's quite unusual in practice.
   </para>

   <para>
    In some query plans, it is possible for a subplan node to be executed more
    than once.  For example, the inner index scan will be executed once per
    outer row in the above nested-loop plan.  In such cases, the
    <literal>loops</literal> value reports the
    total number of executions of the node, and the actual time and rows
    values shown are averages per-execution.  This is done to make the numbers
    comparable with the way that the cost estimates are shown.  Multiply by
    the <literal>loops</literal> value to get the total time actually spent in
    the node.  In the above example, we spent a total of 0.030 milliseconds
    executing the index scans on <literal>tenk2</literal>.
   </para>

   <para>
    In some cases <command>EXPLAIN ANALYZE</command> shows additional execution
    statistics beyond the plan node execution times and row counts.
    For example, Sort and Hash nodes provide extra information:

<screen>
EXPLAIN ANALYZE SELECT *
FROM tenk1 t1, tenk2 t2
WHERE t1.unique1 &lt; 100 AND t1.unique2 = t2.unique2 ORDER BY t1.fivethous;