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

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 6e1f63879dae164b683f575eb70e4bfc6e7a4b66..2110e2d305a5c7fecfda4ac5c5c39325e9ac7f4d 100644 (file)
--- 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
     
     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 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.)