Remove no-longer-accurate claim that REINDEX won't invalidate cached

plans.

diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml
index d6d1a13279e39d59b1a9b8c23cac18069dd96f42..03e2736f794758044ce57f79f9fa9064d29d6ae8 100644 (file)
--- a/doc/src/sgml/ref/reindex.sgml
+++ b/doc/src/sgml/ref/reindex.sgml
@@ -1,5 +1,5 @@
 
 
@@ -231,9 +231,7 @@ REINDEX { INDEX | TABLE | DATABASE | SYSTEM } nam
    subsequent CREATE INDEX locks out writes but not reads; since
    the index is not there, no read will attempt to use it, meaning that there
    will be no blocking but reads might be forced into expensive sequential
-   scans.  Another important point is that the drop/create approach
-   invalidates any cached query plans that use the index, while
-   REINDEX does not.
+   scans.