Hi,
Bruce asked me to look for places in the docs that mention that an
ANALYZE is recommended, to mention the possibility that autovacuum takes
care. This patch does that.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Index: doc/src/sgml/backup.sgml
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/backup.sgml,v
retrieving revision 2.124
diff -c -p -r2.124 backup.sgml
*** doc/src/sgml/backup.sgml 7 Apr 2009 00:31:25 -0000 2.124
--- doc/src/sgml/backup.sgml 28 Apr 2009 21:38:12 -0000
*************** pg_dump -h <replaceable>host1</> <replac
*** 171,177 ****
database so the query optimizer has useful statistics. An easy way
to do this is to run <command>vacuumdb -a -z</>; this is
equivalent to running <command>VACUUM ANALYZE</> on each database
! manually. For more advice on how to load large amounts of data
into <productname>PostgreSQL</> efficiently, refer to <xref
linkend="populate">.
</para>
--- 171,178 ----
database so the query optimizer has useful statistics. An easy way
to do this is to run <command>vacuumdb -a -z</>; this is
equivalent to running <command>VACUUM ANALYZE</> on each database
! manually. Alternatively, you can let the autovacuum daemon do it.
! For more advice on how to load large amounts of data
into <productname>PostgreSQL</> efficiently, refer to <xref
linkend="populate">.
</para>
Index: doc/src/sgml/indices.sgml
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/indices.sgml,v
retrieving revision 1.76
diff -c -p -r1.76 indices.sgml
*** doc/src/sgml/indices.sgml 7 Feb 2009 20:05:44 -0000 1.76
--- doc/src/sgml/indices.sgml 28 Apr 2009 19:48:25 -0000
*************** SELECT am.amname AS index_method,
*** 1012,1018 ****
<listitem>
<para>
Always run <xref linkend="sql-analyze" endterm="sql-analyze-title">
! first. This command
collects statistics about the distribution of the values in the
table. This information is required to guess the number of rows
returned by a query, which is needed by the planner to assign
--- 1012,1018 ----
<listitem>
<para>
Always run <xref linkend="sql-analyze" endterm="sql-analyze-title">
! first (or ensure that the autovacuum daemon did it recently). This command
collects statistics about the distribution of the values in the
table. This information is required to guess the number of rows
returned by a query, which is needed by the planner to assign
Index: doc/src/sgml/perform.sgml
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/perform.sgml,v
retrieving revision 1.69
diff -c -p -r1.69 perform.sgml
*** doc/src/sgml/perform.sgml 13 Dec 2008 19:13:43 -0000 1.69
--- doc/src/sgml/perform.sgml 28 Apr 2009 19:47:58 -0000
*************** SELECT * FROM x, y, a, b, c WHERE someth
*** 961,967 ****
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.
</para>
</sect2>
--- 961,969 ----
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. Note that it is possible that the autovacuum daemon
! will automatically run <command>ANALYZE</command> for you in some
! cases, if enabled.
</para>
</sect2>
*************** SELECT * FROM x, y, a, b, c WHERE someth
*** 1015,1021 ****
</listitem>
<listitem>
<para>
! Run <command>ANALYZE</> afterwards.
</para>
</listitem>
</itemizedlist>
--- 1017,1024 ----
</listitem>
<listitem>
<para>
! Run <command>ANALYZE</> afterwards. (Or let the autovacuum daemon
! do it.)
</para>
</listitem>
</itemizedlist>
*************** SELECT * FROM x, y, a, b, c WHERE someth
*** 1041,1047 ****
while loading the data, but don't bother increasing
<varname>maintenance_work_mem</varname>; rather, you'd do that while
manually recreating indexes and foreign keys afterwards.
! And don't forget to <command>ANALYZE</> when you're done.
</para>
</sect2>
</sect1>
--- 1044,1051 ----
while loading the data, but don't bother increasing
<varname>maintenance_work_mem</varname>; rather, you'd do that while
manually recreating indexes and foreign keys afterwards.
! And don't forget to <command>ANALYZE</> when you're done, or let
! the autovacuum daemon do it.
</para>
</sect2>
</sect1>
Index: doc/src/sgml/ref/pg_dump.sgml
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/ref/pg_dump.sgml,v
retrieving revision 1.113
diff -c -p -r1.113 pg_dump.sgml
*** doc/src/sgml/ref/pg_dump.sgml 22 Mar 2009 16:44:26 -0000 1.113
--- doc/src/sgml/ref/pg_dump.sgml 28 Apr 2009 19:51:57 -0000
*************** CREATE DATABASE foo WITH TEMPLATE templa
*** 834,840 ****
does not contain the statistics used by the optimizer to make
query planning decisions. Therefore, it is wise to run
<command>ANALYZE</command> after restoring from a dump file
! to ensure good performance. The dump file also does not
contain any <command>ALTER DATABASE ... SET</> commands;
these settings are dumped by <xref linkend="app-pg-dumpall">,
along with database users and other installation-wide settings.
--- 834,841 ----
does not contain the statistics used by the optimizer to make
query planning decisions. Therefore, it is wise to run
<command>ANALYZE</command> after restoring from a dump file
! to ensure good performance, or to let the autovacuum daemon do
! it. The dump file also does not
contain any <command>ALTER DATABASE ... SET</> commands;
these settings are dumped by <xref linkend="app-pg-dumpall">,
along with database users and other installation-wide settings.
Index: doc/src/sgml/ref/pg_restore.sgml
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/ref/pg_restore.sgml,v
retrieving revision 1.81
diff -c -p -r1.81 pg_restore.sgml
*** doc/src/sgml/ref/pg_restore.sgml 20 Mar 2009 09:21:08 -0000 1.81
--- doc/src/sgml/ref/pg_restore.sgml 28 Apr 2009 19:50:15 -0000
*************** CREATE DATABASE foo WITH TEMPLATE templa
*** 679,685 ****
<para>
Once restored, it is wise to run <command>ANALYZE</> on each
! restored table so the optimizer has useful statistics.
</para>
</refsect1>
--- 679,686 ----
<para>
Once restored, it is wise to run <command>ANALYZE</> on each
! restored table so the optimizer has useful statistics, or let
! the autovacuum daemon do it.
</para>
</refsect1>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
