diff options
author | Bruce Momjian | 2007-09-13 23:43:35 +0000 |
---|---|---|
committer | Bruce Momjian | 2007-09-13 23:43:35 +0000 |
commit | f307fe4c9bbc6a0a23c5c661a2ad1151eb969367 (patch) | |
tree | 61f8e5a092b5ac68a13060cd52f1ec8284ca371b | |
parent | 3e805fdcf72683a0cacd0706bcb39e9503813fc4 (diff) |
Update documentation to emphasize autovacuum rather than
administrator-scheduled vacuums.
-rw-r--r-- | doc/src/sgml/maintenance.sgml | 77 |
1 files changed, 33 insertions, 44 deletions
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 8090bbe8387..d82d0c54e3f 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -1,4 +1,4 @@ -<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.78 2007/08/19 01:41:24 adunstan Exp $ --> +<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.79 2007/09/13 23:43:35 momjian Exp $ --> <chapter id="maintenance"> <title>Routine Database Maintenance Tasks</title> @@ -59,8 +59,9 @@ </indexterm> <para> - <productname>PostgreSQL</productname>'s <command>VACUUM</> command - <emphasis>must</emphasis> be run on a regular basis for several reasons: + <productname>PostgreSQL</productname>'s <command>VACUUM</> (<xref + linkend="sql-vacuum"> command has to run on a regular basis for several + reasons: <orderedlist> <listitem> @@ -78,14 +79,6 @@ <firstterm>transaction ID wraparound</>.</simpara> </listitem> </orderedlist> - - The frequency and scope of the <command>VACUUM</> operations - performed for each of these reasons will vary depending on the - needs of each site. Therefore, database administrators must - understand these issues and develop an appropriate maintenance - strategy. This section concentrates on explaining the high-level - issues; for details about command syntax and so on, see the <xref - linkend="sql-vacuum" endterm="sql-vacuum-title"> reference page. </para> <para> @@ -103,13 +96,14 @@ </para> <para> - An automated mechanism for performing the necessary <command>VACUUM</> - operations has been added in <productname>PostgreSQL</productname> 8.1. - See <xref linkend="autovacuum">. + Fortunately, autovacuum (<xref linkend="autovacuum">) monitors table + activity and performs <command>VACUUM</command>s when necessary. + Autovacuum works dynamically so it is often better + administration-scheduled vacuuming. </para> <sect2 id="vacuum-for-space-recovery"> - <title>Recovering disk space</title> + <title>Recovering Disk Space</title> <indexterm zone="vacuum-for-space-recovery"> <primary>disk space</primary> @@ -129,17 +123,6 @@ </para> <para> - Clearly, a table that receives frequent updates or deletes will need - to be vacuumed more often than tables that are seldom updated. It - might be useful to set up periodic <application>cron</> tasks that - <command>VACUUM</command> only selected tables, skipping tables that are known not to - change often. This is only likely to be helpful if you have both - large heavily-updated tables and large seldom-updated tables — the - extra cost of vacuuming a small table isn't enough to be worth - worrying about. - </para> - - <para> There are two variants of the <command>VACUUM</command> command. The first form, known as <quote>lazy vacuum</quote> or just <command>VACUUM</command>, marks dead data in tables and @@ -167,30 +150,36 @@ </para> <para> - The standard form of <command>VACUUM</> is best used with the goal - of maintaining a fairly level steady-state usage of disk space. If - you need to return disk space to the operating system, you can use - <command>VACUUM FULL</> — but what's the point of releasing disk - space that will only have to be allocated again soon? Moderately - frequent standard <command>VACUUM</> runs are a better approach - than infrequent <command>VACUUM FULL</> runs for maintaining - heavily-updated tables. However, if some heavily-updated tables - have gone too long with infrequent <command>VACUUM</>, you can + Fortunately, autovacuum (<xref linkend="autovacuum">) monitors table + activity and performs <command>VACUUM</command>s when necessary. This + eliminates the need for administrators to worry about disk space + recovery in all but the most unusual cases. + </para> + + <para> + For administrators who want to control <command>VACUUM</command> + themselves, the standard form of <command>VACUUM</> is best used to + maintain a steady-state usage of disk space. If you need to return + disk space to the operating system, you can use <command>VACUUM + FULL</>, but this is unwise if the table will just grow again in the + future. Moderately-frequent standard <command>VACUUM</> runs are a + better approach than infrequent <command>VACUUM FULL</> runs for + maintaining heavily-updated tables. However, if some heavily-updated + tables have gone too long with infrequent <command>VACUUM</>, you can use <command>VACUUM FULL</> or <command>CLUSTER</> to get performance back (it is much slower to scan a table containing almost only dead rows). </para> <para> - Recommended practice for most sites is to schedule a database-wide - <command>VACUUM</> once a day at a low-usage time of day, - supplemented by more frequent vacuuming of heavily-updated tables - if necessary. (Some installations with extremely high update rates - vacuum their busiest tables as often as once every few minutes.) - If you have multiple databases - in a cluster, don't forget to <command>VACUUM</command> each one; - the program <xref linkend="app-vacuumdb" endterm="app-vacuumdb-title"> - might be helpful. + For those not using autovacuum, one approach is to schedule a + database-wide <command>VACUUM</> once a day during low-usage period, + supplemented by more frequent vacuuming of heavily-updated tables if + necessary. (Some installations with extremely high update rates vacuum + their busiest tables as often as once every few minutes.) If you have + multiple databases in a cluster, don't forget to + <command>VACUUM</command> each one; the program <xref + linkend="app-vacuumdb" endterm="app-vacuumdb-title"> might be helpful. </para> <para> |