From: Alvaro Herrera Date: Fri, 7 Aug 2009 20:55:05 +0000 (+0000) Subject: Document that autovacuum may run ANALYZE X-Git-Tag: REL8_4_1~34 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=8a62c9a95766832a204400aaa3468c6c31d74765;p=postgresql Document that autovacuum may run ANALYZE --- diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml index b280859dea..b646c7c598 100644 --- a/doc/src/sgml/backup.sgml +++ b/doc/src/sgml/backup.sgml @@ -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 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 . diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml index 974e1415f6..3c78ebcd84 100644 --- a/doc/src/sgml/indices.sgml +++ b/doc/src/sgml/indices.sgml @@ -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. diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 019d3f2c57..b45373885f 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -1,4 +1,4 @@ - + Routine Database Maintenance Tasks @@ -253,7 +253,7 @@ - Updating Planner Statistics + Updating Planner Statistics statistics diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml index 1a631d3d91..43081a42b1 100644 --- a/doc/src/sgml/perform.sgml +++ b/doc/src/sgml/perform.sgml @@ -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. diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml index 0f5068ef32..dbc7162b51 100644 --- a/doc/src/sgml/ref/pg_dump.sgml +++ b/doc/src/sgml/ref/pg_dump.sgml @@ -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. diff --git a/doc/src/sgml/ref/pg_restore.sgml b/doc/src/sgml/ref/pg_restore.sgml index 053bcba87d..f077a5bfc6 100644 --- a/doc/src/sgml/ref/pg_restore.sgml +++ b/doc/src/sgml/ref/pg_restore.sgml @@ -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.