name to explicitly indicate that
      inheritance child tables (or partitions) are to be analyzed.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">column_name</replaceable></term>
    <listitem>
     <para>
      The name of a specific column to analyze. Defaults to all columns.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1>
  <title>Outputs</title>

   <para>
    When <literal>VERBOSE</literal> is specified, <command>ANALYZE</command> emits
    progress messages to indicate which table is currently being
    processed.  Various statistics about the tables are printed as well.
   </para>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   To analyze a table, one must ordinarily have the <literal>MAINTAIN</literal>
   privilege on the table.  However, database owners are allowed to
   analyze all tables in their databases, except shared catalogs.
   <command>ANALYZE</command> will skip over any tables that the calling user
   does not have permission to analyze.
  </para>

  <para>
   Foreign tables are analyzed only when explicitly selected.  Not all
   foreign data wrappers support <command>ANALYZE</command>.  If the table's
   wrapper does not support <command>ANALYZE</command>, the command prints a
   warning and does nothing.
  </para>

  <para>
   In the default <productname>PostgreSQL</productname> configuration,
   the autovacuum daemon (see <xref linkend="autovacuum"/>)
   takes care of automatic analyzing of tables when they are first loaded
   with data, and as they change throughout regular operation.
   When autovacuum is disabled,
   it is a good idea to run <command>ANALYZE</command> periodically, or
   just after making major changes in the contents of a table.  Accurate
   statistics will help the planner to choose the most appropriate query
   plan, and thereby improve the speed of query processing.  A common
   strategy for read-mostly databases is to run <link linkend="sql-vacuum"><command>VACUUM</command></link>
   and <command>ANALYZE</command> once a day during a low-usage time of day.
   (This will not be sufficient if there is heavy update activity.)
  </para>

  <para>
   While <command>ANALYZE</command> is running, the <xref
   linkend="guc-search-path"/> is temporarily changed to <literal>pg_catalog,
   pg_temp</literal>.
  </para>

  <para>
   <command>ANALYZE</command>
   requires only a read lock on the target table, so it can run in
   parallel with other non-DDL activity on the table.
  </para>

  <para>
   The statistics collected by <command>ANALYZE</command> usually
   include a list of some of the most common values in each column and
   a histogram showing the approximate data distribution in each
   column.  One or both of these can be omitted if
   <command>ANALYZE</command> deems them uninteresting (for example,
   in a unique-key column, there are no common values) or if the
   column data type does not support the appropriate operators.  There
   is more information about the statistics in <xref
   linkend="maintenance"/>.
  </para>

  <para>
   For large tables, <command>ANALYZE</command> takes a random sample
   of the table contents, rather than examining every row.  This
   allows even very large tables to be analyzed in a small amount of
   time.  Note, however, that the statistics are only approximate, and
   will change slightly each time <command>ANALYZE</command> is run,
   even if the actual table contents did not change.  This might result
   in small changes in the planner's estimated costs shown by
   <link linkend="sql-explain"><command>EXPLAIN</command></link>.
   In rare situations, this non-determinism will cause the planner's
   choices of query plans to change after <command>ANALYZE</command> is run.
   To avoid this, raise the amount of statistics collected by
   <command>ANALYZE</command>, as described below.
  </para>

  <para>
   The extent of analysis