supplement or replace the daemon's activities with manually-managed
   <command>VACUUM</command> commands, which typically are executed according to a
   schedule by <application>cron</application> or <application>Task
   Scheduler</application> scripts.  To set up manually-managed vacuuming properly,
   it is essential to understand the issues discussed in the next few
   subsections.  Administrators who rely on autovacuuming may still wish
   to skim this material to help them understand and adjust autovacuuming.
  </para>

  <sect2 id="vacuum-basics">
   <title>Vacuuming Basics</title>

   <para>
    <productname>PostgreSQL</productname>'s
    <link linkend="sql-vacuum"><command>VACUUM</command></link> command has to
    process each table on a regular basis for several reasons:

    <orderedlist>
     <listitem>
      <simpara>To recover or reuse disk space occupied by updated or deleted
      rows.</simpara>
     </listitem>

     <listitem>
      <simpara>To update data statistics used by the
      <productname>PostgreSQL</productname> query planner.</simpara>
     </listitem>

     <listitem>
      <simpara>To update the visibility map, which speeds
      up <link linkend="indexes-index-only-scans">index-only
      scans</link>.</simpara>
     </listitem>

     <listitem>
      <simpara>To protect against loss of very old data due to
      <firstterm>transaction ID wraparound</firstterm> or
      <firstterm>multixact ID wraparound</firstterm>.</simpara>
     </listitem>
    </orderedlist>

    Each of these reasons dictates performing <command>VACUUM</command> operations
    of varying frequency and scope, as explained in the following subsections.
   </para>

   <para>
    There are two variants of <command>VACUUM</command>: standard <command>VACUUM</command>
    and <command>VACUUM FULL</command>.  <command>VACUUM FULL</command> can reclaim more
    disk space but runs much more slowly.  Also,
    the standard form of <command>VACUUM</command> can run in parallel with production
    database operations.  (Commands such as <command>SELECT</command>,
    <command>INSERT</command>, <command>UPDATE</command>, and
    <command>DELETE</command> will continue to function normally, though you
    will not be able to modify the definition of a table with commands such as
    <command>ALTER TABLE</command> while it is being vacuumed.)
    <command>VACUUM FULL</command> requires an
    <literal>ACCESS EXCLUSIVE</literal> lock on the table it is
    working on, and therefore cannot be done in parallel with other use
    of the table.  Generally, therefore,
    administrators should strive to use standard <command>VACUUM</command> and
    avoid <command>VACUUM FULL</command>.
   </para>

   <para>
    <command>VACUUM</command> creates a substantial amount of I/O
    traffic, which can cause poor performance for other active sessions.
    There are configuration parameters that can be adjusted to reduce the
    performance impact of background vacuuming &mdash; 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>.