granicus.if.org Git - postgresql/blob - doc/src/sgml/ref/analyze.sgml

   1 <!--
   2 doc/src/sgml/ref/analyze.sgml
   3 PostgreSQL documentation
   4 -->
   5
   6 <refentry id="SQL-ANALYZE">
   7  <refmeta>
   8   <refentrytitle>ANALYZE</refentrytitle>
   9   <manvolnum>7</manvolnum>
  10   <refmiscinfo>SQL - Language Statements</refmiscinfo>
  11  </refmeta>
  12
  13  <refnamediv>
  14   <refname>ANALYZE</refname>
  15   <refpurpose>collect statistics about a database</refpurpose>
  16  </refnamediv>
  17
  18  <indexterm zone="sql-analyze">
  19   <primary>ANALYZE</primary>
  20  </indexterm>
  21
  22  <refsynopsisdiv>
  23 <synopsis>
  24 ANALYZE [ VERBOSE ] [ <replaceable class="PARAMETER">table_name</replaceable> [ ( <replaceable class="PARAMETER">column_name</replaceable> [, ...] ) ] ]
  25 </synopsis>
  26  </refsynopsisdiv>
  27
  28  <refsect1>
  29   <title>Description</title>
  30
  31   <para>
  32    <command>ANALYZE</command> collects statistics about the contents
  33    of tables in the database, and stores the results in the <link
  34    linkend="catalog-pg-statistic"><structname>pg_statistic</></>
  35    system catalog.  Subsequently, the query planner uses these
  36    statistics to help determine the most efficient execution plans for
  37    queries.
  38   </para>
  39
  40   <para>
  41    With no parameter, <command>ANALYZE</command> examines every table in the
  42    current database.  With a parameter, <command>ANALYZE</command> examines
  43    only that table.  It is further possible to give a list of column names,
  44    in which case only the statistics for those columns are collected.
  45   </para>
  46  </refsect1>
  47
  48  <refsect1>
  49   <title>Parameters</title>
  50
  51   <variablelist>
  52    <varlistentry>
  53     <term><literal>VERBOSE</literal></term>
  54     <listitem>
  55      <para>
  56       Enables display of progress messages.
  57      </para>
  58     </listitem>
  59    </varlistentry>
  60
  61    <varlistentry>
  62     <term><replaceable class="PARAMETER">table_name</replaceable></term>
  63     <listitem>
  64      <para>
  65       The name (possibly schema-qualified) of a specific table to
  66       analyze.  If omitted, all regular tables (but not foreign tables)
  67       in the current database are analyzed.
  68      </para>
  69     </listitem>
  70    </varlistentry>
  71
  72    <varlistentry>
  73     <term><replaceable class="PARAMETER">column_name</replaceable></term>
  74     <listitem>
  75      <para>
  76       The name of a specific column to analyze. Defaults to all columns.
  77      </para>
  78     </listitem>
  79    </varlistentry>
  80   </variablelist>
  81  </refsect1>
  82
  83  <refsect1>
  84   <title>Outputs</title>
  85
  86    <para>
  87     When <literal>VERBOSE</> is specified, <command>ANALYZE</> emits
  88     progress messages to indicate which table is currently being
  89     processed.  Various statistics about the tables are printed as well.
  90    </para>
  91  </refsect1>
  92
  93  <refsect1>
  94   <title>Notes</title>
  95
  96   <para>
  97    Foreign tables are analyzed only when explicitly selected.  Not all
  98    foreign data wrappers support <command>ANALYZE</>.  If the table's
  99    wrapper does not support <command>ANALYZE</>, the command prints a
 100    warning and does nothing.
 101   </para>
 102
 103   <para>
 104    In the default <productname>PostgreSQL</productname> configuration,
 105    the autovacuum daemon (see <xref linkend="autovacuum">)
 106    takes care of automatic analyzing of tables when they are first loaded
 107    with data, and as they change throughout regular operation.
 108    When autovacuum is disabled,
 109    it is a good idea to run <command>ANALYZE</command> periodically, or
 110    just after making major changes in the contents of a table.  Accurate
 111    statistics will help the planner to choose the most appropriate query
 112    plan, and thereby improve the speed of query processing.  A common
 113    strategy for read-mostly databases is to run <xref linkend="sql-vacuum">
 114    and <command>ANALYZE</command> once a day during a low-usage time of day.
 115    (This will not be sufficient if there is heavy update activity.)
 116   </para>
 117
 118   <para>
 119    <command>ANALYZE</command>
 120    requires only a read lock on the target table, so it can run in
 121    parallel with other activity on the table.
 122   </para>
 123
 124   <para>
 125    The statistics collected by <command>ANALYZE</command> usually
 126    include a list of some of the most common values in each column and
 127    a histogram showing the approximate data distribution in each
 128    column.  One or both of these can be omitted if
 129    <command>ANALYZE</command> deems them uninteresting (for example,
 130    in a unique-key column, there are no common values) or if the
 131    column data type does not support the appropriate operators.  There
 132    is more information about the statistics in <xref
 133    linkend="maintenance">.
 134   </para>
 135
 136   <para>
 137    For large tables, <command>ANALYZE</command> takes a random sample
 138    of the table contents, rather than examining every row.  This
 139    allows even very large tables to be analyzed in a small amount of
 140    time.  Note, however, that the statistics are only approximate, and
 141    will change slightly each time <command>ANALYZE</command> is run,
 142    even if the actual table contents did not change.  This might result
 143    in small changes in the planner's estimated costs shown by
 144    <xref linkend="sql-explain">.
 145    In rare situations, this non-determinism will cause the planner's
 146    choices of query plans to change after <command>ANALYZE</command> is run.
 147    To avoid this, raise the amount of statistics collected by
 148    <command>ANALYZE</command>, as described below.
 149   </para>
 150
 151   <para>
 152    The extent of analysis can be controlled by adjusting the
 153    <xref linkend="guc-default-statistics-target"> configuration variable, or
 154    on a column-by-column basis by setting the per-column statistics
 155    target with <command>ALTER TABLE ... ALTER COLUMN ... SET
 156    STATISTICS</command> (see <xref linkend="sql-altertable">).
 157    The target value sets the
 158    maximum number of entries in the most-common-value list and the
 159    maximum number of bins in the histogram.  The default target value
 160    is 100, but this can be adjusted up or down to trade off accuracy of
 161    planner estimates against the time taken for
 162    <command>ANALYZE</command> and the amount of space occupied in
 163    <literal>pg_statistic</literal>.  In particular, setting the
 164    statistics target to zero disables collection of statistics for
 165    that column.  It might be useful to do that for columns that are
 166    never used as part of the <literal>WHERE</>, <literal>GROUP BY</>,
 167    or <literal>ORDER BY</> clauses of queries, since the planner will
 168    have no use for statistics on such columns.
 169   </para>
 170
 171   <para>
 172    The largest statistics target among the columns being analyzed determines
 173    the number of table rows sampled to prepare the statistics.  Increasing
 174    the target causes a proportional increase in the time and space needed
 175    to do <command>ANALYZE</command>.
 176   </para>
 177
 178   <para>
 179    One of the values estimated by <command>ANALYZE</command> is the number of
 180    distinct values that appear in each column.  Because only a subset of the
 181    rows are examined, this estimate can sometimes be quite inaccurate, even
 182    with the largest possible statistics target.  If this inaccuracy leads to
 183    bad query plans, a more accurate value can be determined manually and then
 184    installed with
 185    <command>ALTER TABLE ... ALTER COLUMN ... SET (n_distinct = ...)</>
 186    (see <xref linkend="sql-altertable">).
 187   </para>
 188
 189   <para>
 190     If the table being analyzed has one or more children,
 191     <command>ANALYZE</command> will gather statistics twice: once on the
 192     rows of the parent table only, and a second time on the rows of the
 193     parent table with all of its children.  This second set of statistics
 194     is needed when planning queries that traverse the entire inheritance
 195     tree.  The autovacuum daemon, however, will only consider inserts or
 196     updates on the parent table itself when deciding whether to trigger an
 197     automatic analyze for that table.  If that table is rarely inserted into
 198     or updated, the inheritance statistics will not be up to date unless you
 199     run <command>ANALYZE</command> manually.
 200   </para>
 201
 202   <para>
 203     If the table being analyzed is completely empty, <command>ANALYZE</command>
 204     will not record new statistics for that table.  Any existing statistics
 205     will be retained.
 206   </para>
 207  </refsect1>
 208
 209  <refsect1>
 210   <title>Compatibility</title>
 211
 212   <para>
 213    There is no <command>ANALYZE</command> statement in the SQL standard.
 214   </para>
 215  </refsect1>
 216
 217  <refsect1>
 218   <title>See Also</title>
 219
 220   <simplelist type="inline">
 221    <member><xref linkend="sql-vacuum"></member>
 222    <member><xref linkend="app-vacuumdb"></member>
 223    <member><xref linkend="runtime-config-resource-vacuum-cost"></member>
 224    <member><xref linkend="autovacuum"></member>
 225   </simplelist>
 226  </refsect1>
 227 </refentry>