bloated to the point that <command>VACUUM FULL</command> is really necessary
    to reclaim space.  Using the autovacuum daemon alleviates this problem,
    since the daemon schedules vacuuming dynamically in response to update
    activity.  It is unwise to disable the daemon completely unless you
    have an extremely predictable workload.  One possible compromise is
    to set the daemon's parameters so that it will only react to unusually
    heavy update activity, thus keeping things from getting out of hand,
    while scheduled <command>VACUUM</command>s are expected to do the bulk of the
    work when the load is typical.
   </para>

   <para>
    For those not using autovacuum, a typical approach is to schedule a
    database-wide <command>VACUUM</command> once a day during a low-usage period,
    supplemented by more frequent vacuuming of heavily-updated tables as
    necessary. (Some installations with extremely high update rates vacuum
    their busiest tables as often as once every few minutes.) If you have
    multiple databases in a cluster, don't forget to
    <command>VACUUM</command> each one; the program <xref
    linkend="app-vacuumdb"/> might be helpful.
   </para>

   <tip>
   <para>
    Plain <command>VACUUM</command> may not be satisfactory when
    a table contains large numbers of dead row versions as a result of
    massive update or delete activity.  If you have such a table and
    you need to reclaim the excess disk space it occupies, you will need
    to use <command>VACUUM FULL</command>, or alternatively
    <link linkend="sql-cluster"><command>CLUSTER</command></link>
    or one of the table-rewriting variants of
    <link linkend="sql-altertable"><command>ALTER TABLE</command></link>.
    These commands rewrite an entire new copy of the table and build
    new indexes for it.  All these options require an
    <literal>ACCESS EXCLUSIVE</literal> lock.  Note that
    they also temporarily use extra disk space approximately equal to the size
    of the table, since the old copies of the table and indexes can't be
    released until the new ones are complete.
   </para>
   </tip>

   <tip>
   <para>
    If you have a table whose entire contents are deleted on a periodic
    basis, consider doing it with
    <link linkend="sql-truncate"><command>TRUNCATE</command></link> rather
    than using <command>DELETE</command> followed by
    <command>VACUUM</command>. <command>TRUNCATE</command> removes the
    entire content of the table immediately, without requiring a
    subsequent <command>VACUUM</command> or <command>VACUUM
    FULL</command> to reclaim the now-unused disk space.
    The disadvantage is that strict MVCC semantics are violated.
   </para>
   </tip>
  </sect2>

  <sect2 id="vacuum-for-statistics">
   <title>Updating Planner Statistics</title>

   <indexterm zone="vacuum-for-statistics">
    <primary>statistics</primary>
    <secondary>of the planner</secondary>
   </indexterm>

   <indexterm zone="vacuum-for-statistics">
    <primary>ANALYZE</primary>
   </indexterm>

   <para>
    The <productname>PostgreSQL</productname> query planner relies on
    statistical information about the contents of tables in order to
    generate good plans for queries.  These statistics are gathered by
    the <link linkend="sql-analyze"><command>ANALYZE</command></link> command,
    which can be invoked by itself or
    as an optional step in <command>VACUUM</command>.  It is important to have
    reasonably accurate statistics, otherwise poor choices of plans might
    degrade database performance.
   </para>

   <para>
    The autovacuum daemon, if enabled, will automatically issue
    <command>ANALYZE</command> commands whenever the content of a table has
    changed sufficiently.  However, administrators might prefer to rely
    on manually-scheduled <command>ANALYZE</command> operations, particularly
    if it is known that update activity on a table will not affect the
    statistics of <quote>interesting</quote>