- linkend="sql-vacuum" endterm="sql-vacuum-title"> reference page.
- 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 <span class="marked">disk s</span>pace
+
Recovering <span class="marked">Disk S</span>pace
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
- 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
+ linkend="app-vacuumdb" endterm="app-vacuumdb-title"> might be helpful.
projects / postgresql.git / commitdiff