-------------------------------------------------------------------&zwsp;------------------------------------------------------
 HashAggregate  (cost=10.77..10.87 rows=10 width=12) (actual time=0.043..0.044 rows=10.00 loops=1)
   Group Key: foo
   Batches: 1  Memory Usage: 24kB
   Buffers: shared hit=4
   ->  Index Scan using test_pkey on test  (cost=0.29..10.27 rows=99 width=8) (actual time=0.009..0.025 rows=99.00 loops=1)
         Index Cond: ((id > 100) AND (id < 200))
         Index Searches: 1
         Buffers: shared hit=4
 Planning Time: 0.244 ms
 Execution Time: 0.073 ms
(10 rows)
</programlisting>
  </para>

  <para>
   Of course, the specific numbers shown here depend on the actual
   contents of the tables involved.  Also note that the numbers, and
   even the selected query strategy, might vary between
   <productname>PostgreSQL</productname> releases due to planner
   improvements. In addition, the <command>ANALYZE</command> command
   uses random sampling to estimate data statistics; therefore, it is
   possible for cost estimates to change after a fresh run of
   <command>ANALYZE</command>, even if the actual distribution of data
   in the table has not changed.
  </para>

  <para>
   Notice that the previous example showed a <quote>custom</quote> plan
   for the specific parameter values given in <command>EXECUTE</command>.
   We might also wish to see the generic plan for a parameterized
   query, which can be done with <literal>GENERIC_PLAN</literal>:

<programlisting>
EXPLAIN (GENERIC_PLAN)
  SELECT sum(bar) FROM test
    WHERE id &gt; $1 AND id &lt; $2
    GROUP BY foo;

                                  QUERY PLAN
-------------------------------------------------------------------&zwsp;------------
 HashAggregate  (cost=26.79..26.89 rows=10 width=12)
   Group Key: foo
   -&gt;  Index Scan using test_pkey on test  (cost=0.29..24.29 rows=500 width=8)
         Index Cond: ((id &gt; $1) AND (id &lt; $2))
(4 rows)
</programlisting>

   In this case the parser correctly inferred that <literal>$1</literal>
   and <literal>$2</literal> should have the same data type
   as <literal>id</literal>, so the lack of parameter type information
   from <command>PREPARE</command> was not a problem.  In other cases
   it might be necessary to explicitly specify types for the parameter
   symbols, which can be done by casting them, for example:

<programlisting>
EXPLAIN (GENERIC_PLAN)
  SELECT sum(bar) FROM test
    WHERE id &gt; $1::integer AND id &lt; $2::integer
    GROUP BY foo;
</programlisting>
  </para>
 </refsect1>

 <refsect1>
  <title>Compatibility</title>

  <para>
   There is no <command>EXPLAIN</command> statement defined in the SQL standard.
  </para>

  <para>
   The following syntax was used before <productname>PostgreSQL</productname>
   version 9.0 and is still supported:
<synopsis>
EXPLAIN [ ANALYZE ] [ VERBOSE ] <replaceable class="parameter">statement</replaceable>
</synopsis>
   Note that in this syntax, the options must be specified in exactly the order
   shown.
  </para>
 </refsect1>

 <refsect1>
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="sql-analyze"/></member>
  </simplelist>
 </refsect1>
</refentry>