Document need for periodic REINDEX in VACUUM FULL cases.

doc/src/sgml/maintenance.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.66 2007/01/16 18:26:02 alvherre Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.67 2007/01/31 04:13:22 momjian Exp $ -->
 
 <chapter id="maintenance">
  <title>Routine Database Maintenance Tasks</title>
@@ -615,9 +615,7 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
    for inefficient use of space: if all but a few index keys on a page have
    been deleted, the page remains allocated.  So a usage pattern in which all
    but a few keys in each range are eventually deleted will see poor use of
-   space.  The potential for bloat is not indefinite &mdash; at worst there
-   will be one key per page &mdash; but it may still be worthwhile to schedule
-   periodic reindexing for indexes that have such usage patterns.
+   space.  For such usage patterns, periodic reindexing is recommended.
   </para>
 
   <para>

doc/src/sgml/ref/vacuum.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.45 2006/12/27 14:55:17 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.46 2007/01/31 04:13:22 momjian Exp $
 PostgreSQL documentation
 -->
 
@@ -167,6 +167,9 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">
     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
+    <command>REINDEX</> is still recommended.  In fact, it is often faster
+    to drop all indexes, <command>VACUUM FULL</>, and recreate the indexes.
    </para>
 
    <para>