Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 9e38d2a

Browse files
committed
Update documentation mention of VACUUM FULL and CLUSTER where
appropriate. Guillaume Cottenceau
1 parent f14f27d commit 9e38d2a

File tree

2 files changed

+15
-9
lines changed

2 files changed

+15
-9
lines changed

doc/src/sgml/maintenance.sgml

+9-4
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.74 2007/05/15 15:52:40 neilc Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.75 2007/05/30 19:45:00 momjian Exp $ -->
22

33
<chapter id="maintenance">
44
<title>Routine Database Maintenance Tasks</title>
@@ -157,7 +157,8 @@
157157
command. This uses a more aggressive algorithm for reclaiming the
158158
space consumed by dead row versions. Any space that is freed by
159159
<command>VACUUM FULL</command> is immediately returned to the
160-
operating system. Unfortunately, this variant of the
160+
operating system, and the table data is physically compacted on
161+
the disk. Unfortunately, this variant of the
161162
<command>VACUUM</command> command acquires an exclusive lock on
162163
each table while <command>VACUUM FULL</command> is processing
163164
it. Therefore, frequently using <command>VACUUM FULL</command> can
@@ -168,12 +169,16 @@
168169
<para>
169170
The standard form of <command>VACUUM</> is best used with the goal
170171
of maintaining a fairly level steady-state usage of disk space. If
171-
you need to return disk space to the operating system you can use
172+
you need to return disk space to the operating system, you can use
172173
<command>VACUUM FULL</> &mdash; but what's the point of releasing disk
173174
space that will only have to be allocated again soon? Moderately
174175
frequent standard <command>VACUUM</> runs are a better approach
175176
than infrequent <command>VACUUM FULL</> runs for maintaining
176-
heavily-updated tables.
177+
heavily-updated tables. However, if some heavily-updated tables
178+
have gone too long with infrequent <command>VACUUM</>, you can
179+
use <command>VACUUM FULL</> or <command>CLUSTER</> to get performance
180+
back (it is much slower to scan a table containing almost only dead
181+
rows).
177182
</para>
178183

179184
<para>

doc/src/sgml/ref/vacuum.sgml

+6-5
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.47 2007/01/31 23:26:04 momjian Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.48 2007/05/30 19:45:01 momjian Exp $
33
PostgreSQL documentation
44
-->
55

@@ -164,10 +164,11 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">
164164
<para>
165165
The <option>FULL</option> option is not recommended for routine use,
166166
but might be useful in special cases. An example is when you have deleted
167-
most of the rows in a table and would like the table to physically shrink
168-
to occupy less disk space. <command>VACUUM FULL</command> will usually
169-
shrink the table more than a plain <command>VACUUM</command> would.
170-
The <option>FULL</option> option does not shrink indexes; a periodic
167+
or updated most of the rows in a table and would like the table to
168+
physically shrink to occupy less disk space and allow faster table
169+
scans. <command>VACUUM FULL</command> will usually shrink the table
170+
more than a plain <command>VACUUM</command> would. The
171+
<option>FULL</option> option does not shrink indexes; a periodic
171172
<command>REINDEX</> is still recommended. In fact, it is often faster
172173
to drop all indexes, <command>VACUUM FULL</>, and recreate the indexes.
173174
</para>

0 commit comments

Comments
 (0)