1- <!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.93 2009/04/23 10:09:11 heikki Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.94 2009/05/16 22:51:24 tgl Exp $ -->
22
33<chapter id="maintenance">
44 <title>Routine Database Maintenance Tasks</title>
375375 </para>
376376
377377 <para>
378- <command>VACUUM</> normally skips pages that don't have any dead row
379- versions, but those pages might still have tuples with old XID values.
380- To replace them too, a scan of the whole table is needed.
381- <xref linkend="guc-vacuum-freeze-table-age"> controls when
382- <command>VACUUM</> does that: a whole table sweep is forced if
383- the table hasn't been fully scanned for <varname>vacuum_freeze_table_age</>
384- - <varname>vacuum_freeze_min_age</> transactions. Setting it to 0
385- makes <command>VACUUM</> to ignore the visibility map and always scan all
386- pages.
387- </para>
388-
389- <para>
390- <xref linkend="guc-vacuum-freeze-min-age">
378+ <xref linkend="guc-vacuum-freeze-min-age">
391379 controls how old an XID value has to be before it's replaced with
392380 <literal>FrozenXID</>. Larger values of this setting
393381 preserve transactional information longer, while smaller values increase
394382 the number of transactions that can elapse before the table must be
395383 vacuumed again.
396384 </para>
397385
386+ <para>
387+ <command>VACUUM</> normally skips pages that don't have any dead row
388+ versions, but those pages might still have row versions with old XID
389+ values. To ensure all old XIDs have been replaced by
390+ <literal>FrozenXID</>, a scan of the whole table is needed.
391+ <xref linkend="guc-vacuum-freeze-table-age"> controls when
392+ <command>VACUUM</> does that: a whole table sweep is forced if
393+ the table hasn't been fully scanned for <varname>vacuum_freeze_table_age</>
394+ minus <varname>vacuum_freeze_min_age</> transactions. Setting it to 0
395+ forces <command>VACUUM</> to always scan all pages, effectively ignoring
396+ the visibility map.
397+ </para>
398+
398399 <para>
399400 The maximum time that a table can go unvacuumed is two billion
400401 transactions minus the <varname>vacuum_freeze_min_age</> that was used
423424 </para>
424425
425426 <para>
426- The effective maximum for <varname>vacuum_table_age </> is 0.95 *
427+ The effective maximum for <varname>vacuum_freeze_table_age </> is 0.95 *
427428 <varname>autovacuum_freeze_max_age</>; a setting higher than that will be
428- capped tothat maximum. A value higher than
429+ capped tothe maximum. A value higher than
429430 <varname>autovacuum_freeze_max_age</> wouldn't make sense because an
430431 anti-wraparound autovacuum would be triggered at that point anyway, and
431432 the 0.95 multiplier leaves some breathing room to run a manual
477478 <structname>pg_database</>. In particular,
478479 the <structfield>relfrozenxid</> column of a table's
479480 <structname>pg_class</> row contains the freeze cutoff XID that was used
480- by the last <command>VACUUM</> for that table. All normal
481+ by the lastwhole-table <command>VACUUM</> for that table. All normal
481482 XIDs older than this cutoff XID are guaranteed to have been replaced by
482483 <literal>FrozenXID</> within the table. Similarly,
483484 the <structfield>datfrozenxid</> column of a database's
@@ -493,12 +494,16 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
493494</programlisting>
494495
495496 The <literal>age</> column measures the number of transactions from the
496- cutoff XID to the current transaction's XID. <command>VACUUM</> normally
497- only scans pages that have been modified since last vacuum, but
497+ cutoff XID to the current transaction's XID.
498+ </para>
499+
500+ <para>
501+ <command>VACUUM</> normally
502+ only scans pages that have been modified since the last vacuum, but
498503 <structfield>relfrozenxid</> can only be advanced when the whole table is
499504 scanned. The whole table is scanned when <structfield>relfrozenxid</> is
500- more than <varname>vacuum_freeze_table_age</> transactions old,if
501- <command>VACUUM FREEZE</> command is used, orif all pages happen to
505+ more than <varname>vacuum_freeze_table_age</> transactions old,when the
506+ <command>VACUUM FREEZE</> command is used, orwhen all pages happen to
502507 require vacuuming to remove dead row versions. When <command>VACUUM</>
503508 scans the whole table, after it's finished <literal>age(relfrozenxid)</>
504509 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".
571576 There is a persistent daemon process, called the
572577 <firstterm>autovacuum launcher</firstterm>, which is in charge of starting
573578 <firstterm>autovacuum worker</firstterm> processes for all databases. The
574- launcher will distribute the work across time,but attempt to start one
579+ launcher will distribute the work across time,attempting to start one
575580 worker on each database every <xref linkend="guc-autovacuum-naptime">
576581 seconds. One worker will be launched for each database, with a maximum
577582 of <xref linkend="guc-autovacuum-max-workers"> processes running at the
578583 same time. If there are more than
579584 <xref linkend="guc-autovacuum-max-workers"> databases to be processed,
580585 the next database will be processed as soon as the first worker finishes.
581- The workerprocesses will check each table within its database and
586+ Each workerprocess will check each table within its database and
582587 execute <command>VACUUM</> and/or <command>ANALYZE</> as needed.
583588 </para>
584589
@@ -621,7 +626,7 @@ vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuple
621626 than <varname>vacuum_freeze_table_age</> transactions old, the whole
622627 table is scanned to freeze old tuples and advance
623628 <structfield>relfrozenxid</>, otherwise only pages that have been modified
624- since last vacuum arevacuumed .
629+ sincethe last vacuum arescanned .
625630 </para>
626631
627632 <para>
@@ -636,7 +641,7 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
636641 <para>
637642 The default thresholds and scale factors are taken from
638643 <filename>postgresql.conf</filename>, but it is possible to override them
639- on a table-by-table basis; see
644+ on a table-by-table basis; see
640645 <xref linkend="sql-createtable-storage-parameters"
641646 endterm="sql-createtable-storage-parameters-title"> for more information.
642647 If a setting
@@ -806,7 +811,7 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
806811 just when you need them the most. Also, on <productname>Linux</>,
807812 <application>syslog</> will sync each message to disk, yielding poor
808813 performance. (You can use a <literal>-</> at the start of the file name
809- in the <application>syslog</> configuration file to disablethis behavior .)
814+ in the <application>syslog</> configuration file to disablesyncing .)
810815 </para>
811816
812817 <para>