<literal>FALSE</literal>.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>FORMAT</literal></term>
    <listitem>
     <para>
      Specify the output format, which can be TEXT, XML, JSON, or YAML.
      Non-text output contains the same information as the text output
      format, but is easier for programs to parse.  This parameter defaults to
      <literal>TEXT</literal>.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">boolean</replaceable></term>
    <listitem>
     <para>
      Specifies whether the selected option should be turned on or off.
      You can write <literal>TRUE</literal>, <literal>ON</literal>, or
      <literal>1</literal> to enable the option, and <literal>FALSE</literal>,
      <literal>OFF</literal>, or <literal>0</literal> to disable it.  The
      <replaceable class="parameter">boolean</replaceable> value can also
      be omitted, in which case <literal>TRUE</literal> is assumed.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">statement</replaceable></term>
    <listitem>
     <para>
      Any <command>SELECT</command>, <command>INSERT</command>, <command>UPDATE</command>,
      <command>DELETE</command>, <command>MERGE</command>,
      <command>VALUES</command>, <command>EXECUTE</command>,
      <command>DECLARE</command>, <command>CREATE TABLE AS</command>, or
      <command>CREATE MATERIALIZED VIEW AS</command> statement, whose execution
      plan you wish to see.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1>
  <title>Outputs</title>

   <para>
    The command's result is a textual description of the plan selected
    for the <replaceable class="parameter">statement</replaceable>,
    optionally annotated with execution statistics.
    <xref linkend="using-explain"/> describes the information provided.
   </para>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   In order to allow the <productname>PostgreSQL</productname> query
   planner to make reasonably informed decisions when optimizing
   queries, the <link
   linkend="catalog-pg-statistic"><structname>pg_statistic</structname></link>
   data should be up-to-date for all tables used in the query.  Normally
   the <link linkend="autovacuum">autovacuum daemon</link> will take care
   of that automatically.  But if a table has recently had substantial
   changes in its contents, you might need to do a manual
   <link linkend="sql-analyze"><command>ANALYZE</command></link> rather than wait for autovacuum to catch up
   with the changes.
  </para>

  <para>
   In order to measure the run-time cost of each node in the execution
   plan, the current implementation of <command>EXPLAIN
   ANALYZE</command> adds profiling overhead to query execution.
   As a result, running <command>EXPLAIN ANALYZE</command>
   on a query can sometimes take significantly longer than executing
   the query normally. The amount of overhead depends on the nature of
   the query, as well as the platform being used.  The worst case occurs
   for plan nodes that in themselves require very little time per
   execution, and on machines that have relatively slow operating
   system calls for obtaining the time of day.
  </para>
 </refsect1>

 <refsect1>
  <title>Examples</title>

  <para>
   To show the plan for a simple query on a table with a single
   <type>integer</type> column and 10000 rows:

<programlisting>
EXPLAIN SELECT * FROM foo;

                       QUERY PLAN
---------------------------------------------------------
 Seq Scan on foo  (cost=0.00..155.00 rows=10000 width=4)
(1 row)
</programlisting>
  </para>

  <para>
  Here is the same query, with JSON output formatting:
<programlisting>
EXPLAIN (FORMAT JSON) SELECT * FROM foo;
           QUERY PLAN
--------------------------------
 [                             +
   {                           +