Update documentation mention of VACUUM FULL and CLUSTER where

appropriate.

Guillaume Cottenceau

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index de8df507eac9cf9894eade3fc9460f5b3127e57f..d0e2ef57e68244cf5301562574c7b950e64e13a4 100644 (file)
--- 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.74 2007/05/15 15:52:40 neilc Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.75 2007/05/30 19:45:00 momjian Exp $ -->
 
 <chapter id="maintenance">
  <title>Routine Database Maintenance Tasks</title>
@@ -157,7 +157,8 @@
     command. This uses a more aggressive algorithm for reclaiming the
     space consumed by dead row versions. Any space that is freed by
     <command>VACUUM FULL</command> is immediately returned to the
-    operating system. Unfortunately, this variant of the
+    operating system, and the table data is physically compacted on
+    the disk. Unfortunately, this variant of the
     <command>VACUUM</command> command acquires an exclusive lock on
     each table while <command>VACUUM FULL</command> is processing
     it. Therefore, frequently using <command>VACUUM FULL</command> can
@@ -168,12 +169,16 @@
    <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
+    you need to return disk space to the operating system, you can use
     <command>VACUUM FULL</> &mdash; 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.
+    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>

diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml
index a2c45b5a0c7933105d36d26620115dd07b051fd6..60bd2ff73e70a7f22ef3bf88d4f3b81bbe4c72d4 100644 (file)
--- a/doc/src/sgml/ref/vacuum.sgml
+++ b/doc/src/sgml/ref/vacuum.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.47 2007/01/31 23:26:04 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.48 2007/05/30 19:45:01 momjian Exp $
 PostgreSQL documentation
 -->
 
@@ -164,10 +164,11 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">
    <para>
     The <option>FULL</option> option is not recommended for routine use,
     but might be useful in special cases.  An example is when you have deleted
-    most of the rows in a table and would like the table to physically shrink
-    to occupy less disk space.  <command>VACUUM FULL</command> will usually
-    shrink the table more than a plain <command>VACUUM</command> would.
-    The <option>FULL</option> option does not shrink indexes; a periodic
+    or updated most of the rows in a table and would like the table to
+    physically shrink to occupy less disk space and allow faster table
+    scans. <command>VACUUM FULL</command> will usually shrink the table
+    more than a plain <command>VACUUM</command> would.  The
+    <option>FULL</option> option does not shrink indexes; a periodic
     <command>REINDEX</> is still recommended.  In fact, it is often faster
     to drop all indexes, <command>VACUUM FULL</>, and recreate the indexes.
    </para>