<para>
After restoring a backup, it is wise to run <xref
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 <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
+ database so the query optimizer has useful statistics;
+ see <xref linkend="vacuum-for-statistics" endterm="vacuum-for-statistics-title">
+ and <xref linkend="autovacuum" endterm="autovacuum-title"> for more information.
+ For more advice on how to load large amounts of data
into <productname>PostgreSQL</> efficiently, refer to <xref
linkend="populate">.
</para>
real statistics, some default values are assumed, which are
almost certain to be inaccurate. Examining an application's
index usage without having run <command>ANALYZE</command> is
- therefore a lost cause.
+ therefore a lost cause.
+ See <xref linkend="vacuum-for-statistics" endterm="vacuum-for-statistics-title">
+ and <xref linkend="autovacuum" endterm="autovacuum-title"> for more information.
</para>
</listitem>
</sect2>
<sect2 id="vacuum-for-statistics">
- <title>Updating Planner Statistics</title>
+ <title id="vacuum-for-statistics-title">Updating Planner Statistics</title>
<indexterm zone="vacuum-for-statistics">
<primary>statistics</primary>
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 <command>ANALYZE</command> automatically; see
+ <xref linkend="vacuum-for-statistics" endterm="vacuum-for-statistics-title">
+ and <xref linkend="autovacuum" endterm="autovacuum-title"> for more information.
</para>
</sect2>
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.
+ And don't forget to <command>ANALYZE</> when you're done; see
+ <xref linkend="vacuum-for-statistics" endterm="vacuum-for-statistics-title">
+ and <xref linkend="autovacuum" endterm="autovacuum-title"> for more information.
</para>
</sect2>
</sect1>
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
+ to ensure good performance; see <xref linkend="vacuum-for-statistics">
+ and <xref linkend="autovacuum"> for more information.
+ 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.
<para>
Once restored, it is wise to run <command>ANALYZE</> on each
- restored table so the optimizer has useful statistics.
+ restored table so the optimizer has useful statistics; see
+ <xref linkend="vacuum-for-statistics"> and
+ <xref linkend="autovacuum"> for more information.
</para>
</refsect1>