From f307fe4c9bbc6a0a23c5c661a2ad1151eb969367 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Thu, 13 Sep 2007 23:43:35 +0000 Subject: [PATCH] Update documentation to emphasize autovacuum rather than administrator-scheduled vacuums. --- doc/src/sgml/maintenance.sgml | 77 +++++++++++++++-------------------- 1 file changed, 33 insertions(+), 44 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 8090bbe838..d82d0c54e3 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -1,4 +1,4 @@ - + Routine Database Maintenance Tasks @@ -59,8 +59,9 @@ - PostgreSQL's VACUUM command - must be run on a regular basis for several reasons: + PostgreSQL's VACUUM ( command has to run on a regular basis for several + reasons: @@ -78,14 +79,6 @@ transaction ID wraparound. - - The frequency and scope of the 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 reference page. @@ -103,13 +96,14 @@ - An automated mechanism for performing the necessary VACUUM - operations has been added in PostgreSQL 8.1. - See . + Fortunately, autovacuum () monitors table + activity and performs VACUUMs when necessary. + Autovacuum works dynamically so it is often better + administration-scheduled vacuuming. - Recovering disk space + Recovering Disk Space disk space @@ -128,17 +122,6 @@ space requirements. This is done by running VACUUM. - - 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 cron tasks that - VACUUM 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. - - There are two variants of the VACUUM command. The first form, known as lazy vacuum or @@ -167,30 +150,36 @@ - The standard form of 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 - VACUUM FULL — but what's the point of releasing disk - space that will only have to be allocated again soon? Moderately - frequent standard VACUUM runs are a better approach - than infrequent VACUUM FULL runs for maintaining - heavily-updated tables. However, if some heavily-updated tables - have gone too long with infrequent VACUUM, you can + Fortunately, autovacuum () monitors table + activity and performs VACUUMs when necessary. This + eliminates the need for administrators to worry about disk space + recovery in all but the most unusual cases. + + + + For administrators who want to control VACUUM + themselves, the standard form of 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 VACUUM + FULL, but this is unwise if the table will just grow again in the + future. Moderately-frequent standard VACUUM runs are a + better approach than infrequent VACUUM FULL runs for + maintaining heavily-updated tables. However, if some heavily-updated + tables have gone too long with infrequent VACUUM, you can use VACUUM FULL or CLUSTER to get performance back (it is much slower to scan a table containing almost only dead rows). - Recommended practice for most sites is to schedule a database-wide - 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 VACUUM each one; - the program - might be helpful. + For those not using autovacuum, one approach is to schedule a + database-wide 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 + VACUUM each one; the program might be helpful. -- 2.40.0