Document need for periodic REINDEX in VACUUM FULL cases.

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 8da5c18c1a8ca9d7bd094d53b7af5661c03df78e..4b5b2c5cc328543e9883864d0b1ce065cfa582be 100644 (file)
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Routine Database Maintenance Tasks
@@ -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 — at worst there
-   will be one key per page — 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.
   
 
   

diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml
index f72f36bf392ec169cb2e704150a10afc384a25a7..a9e86a24c800dd3c1f8725788421bd095ced4a69 100644 (file)
--- a/doc/src/sgml/ref/vacuum.sgml
+++ b/doc/src/sgml/ref/vacuum.sgml
@@ -1,5 +1,5 @@
 
 
@@ -167,6 +167,9 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ 
     most of the rows in a table and would like the table to physically shrink
     to occupy less disk space.  VACUUM FULL will usually
     shrink the table more than a plain VACUUM would.
+    The FULL option does not shrink indexes; a periodic
+    REINDEX is still recommended.  In fact, it is often faster
+    to drop all indexes, VACUUM FULL, and recreate the indexes.