Document that autovacuum may run ANALYZE
authorAlvaro Herrera
Fri, 7 Aug 2009 20:54:31 +0000 (20:54 +0000)
committerAlvaro Herrera
Fri, 7 Aug 2009 20:54:31 +0000 (20:54 +0000)
doc/src/sgml/backup.sgml
doc/src/sgml/indices.sgml
doc/src/sgml/maintenance.sgml
doc/src/sgml/perform.sgml
doc/src/sgml/ref/pg_dump.sgml
doc/src/sgml/ref/pg_restore.sgml

index b280859deaa386b6599c733fa3dfd94249fa762f..f9e45ec3d8c5300ea4647cfd8c919a7d2f95e141 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  Backup and Restore
@@ -168,10 +168,10 @@ pg_dump -h host1 dbname | psql -h h
    
     After restoring a backup, it is wise to run 
     linkend="sql-analyze" endterm="sql-analyze-title"> on each
-    database so the query optimizer has useful statistics. An easy way
-    to do this is to run vacuumdb -a -z; this is
-    equivalent to running VACUUM ANALYZE on each database
-    manually.  For more advice on how to load large amounts of data
+    database so the query optimizer has useful statistics;
+    see 
+    and  for more information.
+    For more advice on how to load large amounts of data
     into PostgreSQL efficiently, refer to 
     linkend="populate">.
    
index 974e1415f658733349a74f333766108f0f628356..7801b099f2235b5ff90c23dc908d62ff8e98bb7b 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  Indexes
@@ -1025,7 +1025,9 @@ SELECT am.amname AS index_method,
      real statistics, some default values are assumed, which are
      almost certain to be inaccurate.  Examining an application's
      index usage without having run ANALYZE is
-     therefore a lost cause.
+     therefore a lost cause. 
+     See 
+     and  for more information.
     
    
 
index 019d3f2c5712173b89091e7461a1635ae63d4eff..80b6365226b8377b4678f924f9ad8fc921751958 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  Routine Database Maintenance Tasks
   
 
   
-   Updating Planner Statistics
+    id="vacuum-for-statistics-title">Updating Planner Statistics
 
    
     statistics
index 1a631d3d91f2cc0de5962206227fb00992f30bb3..d1ae3efb33049100a9829ffca907456184ff9d13 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
  
   Performance Tips
@@ -974,7 +974,10 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
     table.  With no statistics or obsolete statistics, the planner might
     make poor decisions during query planning, leading to poor
     performance on any tables with inaccurate or nonexistent
-    statistics.
+    statistics.  Note that if the autovacuum daemon is enabled, it might
+    run ANALYZE automatically; see
+    
+    and  for more information.
    
   
 
@@ -1054,7 +1057,9 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
     while loading the data, but don't bother increasing
     maintenance_work_mem; rather, you'd do that while
     manually recreating indexes and foreign keys afterwards.
-    And don't forget to ANALYZE when you're done.
+    And don't forget to ANALYZE when you're done; see
+    
+    and  for more information.
    
   
   
index 0f5068ef32e50240c00ad9c113d177cde3ab5656..9386ff8109a3aea2e2c633db3c3a10f7b5dfe215 100644 (file)
@@ -1,5 +1,5 @@
 
 
@@ -834,7 +834,9 @@ CREATE DATABASE foo WITH TEMPLATE template0;
    does not contain the statistics used by the optimizer to make
    query planning decisions.  Therefore, it is wise to run
    ANALYZE after restoring from a dump file
-   to ensure good performance.  The dump file also does not
+   to ensure good performance; see 
+   and  for more information.
+   The dump file also does not
    contain any ALTER DATABASE ... SET commands;
    these settings are dumped by ,
    along with database users and other installation-wide settings.
index 053bcba87da29daea960ba15ccfa6d2bcdd3aed5..73ae4c9438594c03f51f34927280c23ebd021c6f 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  
@@ -679,7 +679,9 @@ CREATE DATABASE foo WITH TEMPLATE template0;
 
   
    Once restored, it is wise to run ANALYZE on each
-   restored table so the optimizer has useful statistics.
+   restored table so the optimizer has useful statistics; see
+    and
+    for more information.