vacuuming — see
    <xref linkend="runtime-config-resource-vacuum-cost"/>.
   </para>
  </sect2>

  <sect2 id="vacuum-for-space-recovery">
   <title>Recovering Disk Space</title>

   <indexterm zone="vacuum-for-space-recovery">
    <primary>disk space</primary>
   </indexterm>

   <para>
    In <productname>PostgreSQL</productname>, an
    <command>UPDATE</command> or <command>DELETE</command> of a row does not
    immediately remove the old version of the row.
    This approach is necessary to gain the benefits of multiversion
    concurrency control (<acronym>MVCC</acronym>, see <xref linkend="mvcc"/>): the row version
    must not be deleted while it is still potentially visible to other
    transactions. But eventually, an outdated or deleted row version is no
    longer of interest to any transaction. The space it occupies must then be
    reclaimed for reuse by new rows, to avoid unbounded growth of disk
    space requirements. This is done by running <command>VACUUM</command>.
   </para>

   <para>
    The standard form of <command>VACUUM</command> removes dead row
    versions in tables and indexes and marks the space available for
    future reuse.  However, it will not return the space to the operating
    system, except in the special case where one or more pages at the
    end of a table become entirely free and an exclusive table lock can be
    easily obtained.  In contrast, <command>VACUUM FULL</command> actively compacts
    tables by writing a complete new version of the table file with no dead
    space.  This minimizes the size of the table, but can take a long time.
    It also requires extra disk space for the new copy of the table, until
    the operation completes.
   </para>

   <para>
    The usual goal of routine vacuuming is to do standard <command>VACUUM</command>s
    often enough to avoid needing <command>VACUUM FULL</command>.  The
    autovacuum daemon attempts to work this way, and in fact will
    never issue <command>VACUUM FULL</command>.  In this approach, the idea
    is not to keep tables at their minimum size, but to maintain steady-state
    usage of disk space: each table occupies space equivalent to its
    minimum size plus however much space gets used up between vacuum runs.
    Although <command>VACUUM FULL</command> can be used to shrink a table back
    to its minimum size and return the disk space to the operating system,
    there is not much point in this if the table will just grow again in the
    future.  Thus, moderately-frequent standard <command>VACUUM</command> runs are a
    better approach than infrequent <command>VACUUM FULL</command> runs for
    maintaining heavily-updated tables.
   </para>

   <para>
    Some administrators prefer to schedule vacuuming themselves, for example
    doing all the work at night when load is low.
    The difficulty with doing vacuuming according to a fixed schedule
    is that if a table has an unexpected spike in update activity, it may
    get 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