mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-09 08:10:09 +08:00
Code Issues Packages Projects Releases Wiki Activity

Minor copy-editing for description of partial-table vacuuming.

Browse Source
This commit is contained in:
Tom Lane 2009-05-16 22:51:24 +00:00
parent 03a5ff0d1a
commit 606f5d1763
1 changed files with 31 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
doc/src/sgml/maintenance.sgml
View File

@ -1,4 +1,4 @@
<!-- $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>
@ -375,19 +375,7 @@
</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
@ -395,6 +383,19 @@
vacuumed again.
</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
@ -423,9 +424,9 @@
</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
@ -477,7 +478,7 @@
<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
@ -493,12 +494,16 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
</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
@ -571,14 +576,14 @@ HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
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>
@ -621,7 +626,7 @@ vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuple
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>
@ -636,7 +641,7 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
<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
@ -806,7 +811,7 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
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>