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