From 606f5d17639d9b59cbd0f56e0597666477f8fb88 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 16 May 2009 22:51:24 +0000 Subject: [PATCH] Minor copy-editing for description of partial-table vacuuming. --- doc/src/sgml/maintenance.sgml | 57 +++++++++++++++++++---------------- 1 file changed, 31 insertions(+), 26 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 6e1f63879d..2110e2d305 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -1,4 +1,4 @@ - + Routine Database Maintenance Tasks @@ -375,19 +375,7 @@ - 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. - controls when - VACUUM does that: a whole table sweep is forced if - the table hasn't been fully scanned for vacuum_freeze_table_age - - vacuum_freeze_min_age transactions. Setting it to 0 - makes VACUUM to ignore the visibility map and always scan all - pages. - - - - + controls how old an XID value has to be before it's replaced with FrozenXID. Larger values of this setting preserve transactional information longer, while smaller values increase @@ -395,6 +383,19 @@ vacuumed again. + + 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 + FrozenXID, a scan of the whole table is needed. + controls when + VACUUM does that: a whole table sweep is forced if + the table hasn't been fully scanned for vacuum_freeze_table_age + minus vacuum_freeze_min_age transactions. Setting it to 0 + forces VACUUM to always scan all pages, effectively ignoring + the visibility map. + + The maximum time that a table can go unvacuumed is two billion transactions minus the vacuum_freeze_min_age that was used @@ -423,9 +424,9 @@ - The effective maximum for vacuum_table_age is 0.95 * + The effective maximum for vacuum_freeze_table_age is 0.95 * 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 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 @@ pg_database. In particular, the relfrozenxid column of a table's pg_class row contains the freeze cutoff XID that was used - by the last VACUUM for that table. All normal + by the last whole-table VACUUM for that table. All normal XIDs older than this cutoff XID are guaranteed to have been replaced by FrozenXID within the table. Similarly, the datfrozenxid column of a database's @@ -493,12 +494,16 @@ SELECT datname, age(datfrozenxid) FROM pg_database; The age column measures the number of transactions from the - cutoff XID to the current transaction's XID. VACUUM normally - only scans pages that have been modified since last vacuum, but + cutoff XID to the current transaction's XID. + + + + VACUUM normally + only scans pages that have been modified since the last vacuum, but relfrozenxid can only be advanced when the whole table is scanned. The whole table is scanned when relfrozenxid is - more than vacuum_freeze_table_age transactions old, if - VACUUM FREEZE command is used, or if all pages happen to + more than vacuum_freeze_table_age transactions old, when the + VACUUM FREEZE command is used, or when all pages happen to require vacuuming to remove dead row versions. When VACUUM scans the whole table, after it's finished age(relfrozenxid) should be a little more than the 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 autovacuum launcher, which is in charge of starting autovacuum worker 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 seconds. One worker will be launched for each database, with a maximum of processes running at the same time. If there are more than 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 VACUUM and/or ANALYZE as needed. @@ -621,7 +626,7 @@ vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuple than vacuum_freeze_table_age transactions old, the whole table is scanned to freeze old tuples and advance relfrozenxid, otherwise only pages that have been modified - since last vacuum are vacuumed. + since the last vacuum are scanned. @@ -636,7 +641,7 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu The default thresholds and scale factors are taken from postgresql.conf, but it is possible to override them - on a table-by-table basis; see + on a table-by-table basis; see 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 Linux, syslog will sync each message to disk, yielding poor performance. (You can use a - at the start of the file name - in the syslog configuration file to disable this behavior.) + in the syslog configuration file to disable syncing.) -- 2.40.0