-<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.93 2009/04/23 10:09:11 heikki Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.94 2009/05/16 22:51:24 tgl Exp $ -->
<chapter id="maintenance">
<title>Routine Database Maintenance Tasks</title>
</para>
<para>
- <command>VACUUM</> normally skips pages that don't have any dead row
- versions, but those pages might still have tuples with old XID values.
- To replace them too, a scan of the whole table is needed.
- <xref linkend="guc-vacuum-freeze-table-age"> controls when
- <command>VACUUM</> does that: a whole table sweep is forced if
- the table hasn't been fully scanned for <varname>vacuum_freeze_table_age</>
- - <varname>vacuum_freeze_min_age</> transactions. Setting it to 0
- makes <command>VACUUM</> to ignore the visibility map and always scan all
- pages.
- </para>
-
- <para>
- <xref linkend="guc-vacuum-freeze-min-age">
+ <xref linkend="guc-vacuum-freeze-min-age">
controls how old an XID value has to be before it's replaced with
<literal>FrozenXID</>. Larger values of this setting
preserve transactional information longer, while smaller values increase
</para>
<para>
+ <command>VACUUM</> normally skips pages that don't have any dead row
+ versions, but those pages might still have row versions with old XID
+ values. To ensure all old XIDs have been replaced by
+ <literal>FrozenXID</>, a scan of the whole table is needed.
+ <xref linkend="guc-vacuum-freeze-table-age"> controls when
+ <command>VACUUM</> does that: a whole table sweep is forced if
+ the table hasn't been fully scanned for <varname>vacuum_freeze_table_age</>
+ minus <varname>vacuum_freeze_min_age</> transactions. Setting it to 0
+ forces <command>VACUUM</> to always scan all pages, effectively ignoring
+ the visibility map.
+ </para>
+
+ <para>
The maximum time that a table can go unvacuumed is two billion
transactions minus the <varname>vacuum_freeze_min_age</> that was used
when <command>VACUUM</> last scanned the whole table. If it were to go
</para>
<para>
- The effective maximum for <varname>vacuum_table_age</> is 0.95 *
+ The effective maximum for <varname>vacuum_freeze_table_age</> is 0.95 *
<varname>autovacuum_freeze_max_age</>; a setting higher than that will be
- capped to that maximum. A value higher than
+ capped to the maximum. A value higher than
<varname>autovacuum_freeze_max_age</> wouldn't make sense because an
anti-wraparound autovacuum would be triggered at that point anyway, and
the 0.95 multiplier leaves some breathing room to run a manual
<structname>pg_database</>. In particular,
the <structfield>relfrozenxid</> column of a table's
<structname>pg_class</> row contains the freeze cutoff XID that was used
- by the last <command>VACUUM</> for that table. All normal
+ by the last whole-table <command>VACUUM</> for that table. All normal
XIDs older than this cutoff XID are guaranteed to have been replaced by
<literal>FrozenXID</> within the table. Similarly,
the <structfield>datfrozenxid</> column of a database's
</programlisting>
The <literal>age</> column measures the number of transactions from the
- cutoff XID to the current transaction's XID. <command>VACUUM</> normally
- only scans pages that have been modified since last vacuum, but
+ cutoff XID to the current transaction's XID.
+ </para>
+
+ <para>
+ <command>VACUUM</> normally
+ only scans pages that have been modified since the last vacuum, but
<structfield>relfrozenxid</> can only be advanced when the whole table is
scanned. The whole table is scanned when <structfield>relfrozenxid</> is
- more than <varname>vacuum_freeze_table_age</> transactions old, if
- <command>VACUUM FREEZE</> command is used, or if all pages happen to
+ more than <varname>vacuum_freeze_table_age</> transactions old, when the
+ <command>VACUUM FREEZE</> command is used, or when all pages happen to
require vacuuming to remove dead row versions. When <command>VACUUM</>
scans the whole table, after it's finished <literal>age(relfrozenxid)</>
should be a little more than the <varname>vacuum_freeze_min_age</> setting
There is a persistent daemon process, called the
<firstterm>autovacuum launcher</firstterm>, which is in charge of starting
<firstterm>autovacuum worker</firstterm> processes for all databases. The
- launcher will distribute the work across time, but attempt to start one
+ launcher will distribute the work across time, attempting to start one
worker on each database every <xref linkend="guc-autovacuum-naptime">
seconds. One worker will be launched for each database, with a maximum
of <xref linkend="guc-autovacuum-max-workers"> processes running at the
same time. If there are more than
<xref linkend="guc-autovacuum-max-workers"> databases to be processed,
the next database will be processed as soon as the first worker finishes.
- The worker processes will check each table within its database and
+ Each worker process will check each table within its database and
execute <command>VACUUM</> and/or <command>ANALYZE</> as needed.
</para>
than <varname>vacuum_freeze_table_age</> transactions old, the whole
table is scanned to freeze old tuples and advance
<structfield>relfrozenxid</>, otherwise only pages that have been modified
- since last vacuum are vacuumed.
+ since the last vacuum are scanned.
</para>
<para>
<para>
The default thresholds and scale factors are taken from
<filename>postgresql.conf</filename>, but it is possible to override them
- on a table-by-table basis; see
+ on a table-by-table basis; see
<xref linkend="sql-createtable-storage-parameters"
endterm="sql-createtable-storage-parameters-title"> for more information.
If a setting
just when you need them the most. Also, on <productname>Linux</>,
<application>syslog</> will sync each message to disk, yielding poor
performance. (You can use a <literal>-</> at the start of the file name
- in the <application>syslog</> configuration file to disable this behavior.)
+ in the <application>syslog</> configuration file to disable syncing.)
</para>
<para>
OSDN Git Service
