<command>ANALYZE</command>.
   </para>

   <para>
    Partitioned tables do not directly store tuples and consequently
    are not processed by autovacuum.  (Autovacuum does process table
    partitions just like other tables.)  Unfortunately, this means that
    autovacuum does  not run <command>ANALYZE</command> on partitioned
    tables, and this can cause suboptimal plans for queries that reference
    partitioned table statistics.  You can work around this problem by
    manually running <command>ANALYZE</command> on partitioned tables
    when they are first populated, and again whenever the distribution
    of data in their partitions changes significantly.
   </para>

   <para>
    Temporary tables cannot be accessed by autovacuum.  Therefore,
    appropriate vacuum and analyze operations should be performed via
    session SQL commands.
   </para>

   <para>
    The default thresholds and scale factors are taken from
    <filename>postgresql.conf</filename>, but it is possible to override them
    (and many other autovacuum control parameters) on a per-table basis; see
    <xref linkend="sql-createtable-storage-parameters"/> for more information.
    If a setting has been changed via a table's storage parameters, that value
    is used when processing that table; otherwise the global settings are
    used. See <xref linkend="runtime-config-autovacuum"/> for more details on
    the global settings.
   </para>

   <para>
    When multiple workers are running, the autovacuum cost delay parameters
    (see <xref linkend="runtime-config-resource-vacuum-cost"/>) are
    <quote>balanced</quote> among all the running workers, so that the
    total I/O impact on the system is the same regardless of the number
    of workers actually running.  However, any workers processing tables whose
    per-table <literal>autovacuum_vacuum_cost_delay</literal> or
    <literal>autovacuum_vacuum_cost_limit</literal> storage parameters have been set
    are not considered in the balancing algorithm.
   </para>

   <para>
    Autovacuum workers generally don't block other commands.  If a process
    attempts to acquire a lock that conflicts with the
    <literal>SHARE UPDATE EXCLUSIVE</literal> lock held by autovacuum, lock
    acquisition will interrupt the autovacuum.  For conflicting lock modes,
    see <xref linkend="table-lock-compatibility"/>.  However, if the autovacuum
    is running to prevent transaction ID wraparound (i.e., the autovacuum query
    name in the <structname>pg_stat_activity</structname> view ends with
    <literal>(to prevent wraparound)</literal>), the autovacuum is not
    automatically interrupted.
   </para>

   <warning>
    <para>
     Regularly running commands that acquire locks conflicting with a
     <literal>SHARE UPDATE EXCLUSIVE</literal> lock (e.g., ANALYZE) can
     effectively prevent autovacuums from ever completing.
    </para>
   </warning>
  </sect2>
 </sect1>


 <sect1 id="routine-reindex">
  <title>Routine Reindexing</title>

  <indexterm zone="routine-reindex">
   <primary>reindex</primary>
  </indexterm>

  <para>
   In some situations it is worthwhile to rebuild indexes periodically
   with the <xref linkend="sql-reindex"/> command or a series of individual
   rebuilding steps.

  </para>

  <para>
   B-tree index pages that have become completely empty are reclaimed for
   re-use.  However, there is still a possibility
   of inefficient use of space: if all but a few index keys on a page have
   been deleted, the page remains allocated.  Therefore, a usage
   pattern in which most, but not all, keys in each range are eventually
   deleted will see poor use of space.  For such usage patterns,
   periodic reindexing is recommended.
  </para>

  <para>
   The potential for bloat in non-B-tree indexes has not been well
   researched.  It is a good idea to periodically monitor the index's physical
   size when using any non-B-tree index type.
  </para>

  <para>
   Also, for B-tree indexes, a freshly-constructed