Attached is a committed patch to add a recommendation for ANALYZE after
restore. It is a shame we only have vacuumdb -a to do analyze _and_
vacuum, and no analyze-only option.
---------------------------------------------------------------------------
Tom Lane wrote:
> mlw <[EMAIL PROTECTED]> writes:
> > From an "ease of use" perspective, it would be one less step.
>
> There is something to be said for that. As Rod notes, this has been
> considered and rejected before --- but I think that was back when
> ANALYZE (a) could only be done as part of VACUUM, and (b) insisted on
> scanning the whole table. The current implementation is vastly
> lighter-weight than what we were looking at back then. Perhaps it's
> time to reconsider.
>
> Although I suggested doing a single unconditional ANALYZE at the end
> of the script, second thought leads me to think the per-table ANALYZE
> (probably issued right after the table's data-load step) might be
> better. That way you'd not have any side-effects on already-existing
> tables in the database you are loading to. OTOH, that way would leave
> the system catalogs un-analyzed, which might be bad.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/backup.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/backup.sgml,v
retrieving revision 2.24
diff -c -c -r2.24 backup.sgml
*** doc/src/sgml/backup.sgml 11 Nov 2002 20:14:02 -0000 2.24
--- doc/src/sgml/backup.sgml 17 Mar 2003 23:58:37 -0000
***************
*** 126,131 ****
--- 126,138 ----
</para>
<para>
+ Once restored, it is wise to run <command>ANALYZE</> on each
+ database so the optimizer has useful statistics. You
+ can also run <command>vacuumdb -a -z</> to <command>ANALYZE</> all
+ databases.
+ </para>
+
+ <para>
The ability of <application>pg_dump</> and <application>psql</> to
write to or read from pipes makes it possible to dump a database
directly from one server to another, for example
Index: doc/src/sgml/ref/pg_dump.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/pg_dump.sgml,v
retrieving revision 1.56
diff -c -c -r1.56 pg_dump.sgml
*** doc/src/sgml/ref/pg_dump.sgml 13 Feb 2003 04:54:15 -0000 1.56
--- doc/src/sgml/ref/pg_dump.sgml 17 Mar 2003 23:58:38 -0000
***************
*** 650,655 ****
--- 650,660 ----
</programlisting>
</para>
+ <para>
+ Once restored, it is wise to run <command>ANALYZE</> on each
+ restored object so the optimizer has useful statistics.
+ </para>
+
<para>
<application>pg_dump</application> has a few limitations:
***************
*** 682,687 ****
--- 687,698 ----
other output formats is not limited, except possibly by the
operating system.
</para>
+
+ <para>
+ Once restored, it is wise to run <command>ANALYZE</> on each
+ restored object so the optimizer has useful statistics.
+ </para>
+
</refsect1>
<refsect1 id="pg-dump-examples">
Index: doc/src/sgml/ref/pg_dumpall.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/pg_dumpall.sgml,v
retrieving revision 1.36
diff -c -c -r1.36 pg_dumpall.sgml
*** doc/src/sgml/ref/pg_dumpall.sgml 6 Jan 2003 18:53:24 -0000 1.36
--- doc/src/sgml/ref/pg_dumpall.sgml 17 Mar 2003 23:58:38 -0000
***************
*** 258,267 ****
<application>pg_dumpall</application> will need to connect several
times to the <productname>PostgreSQL</productname> server. If password
authentication is configured, it will ask for a password each time. In
! that case it would be convenient to set up a password file.
</para>
- <comment>But where is that password file documented?</comment>
</refsect1>
--- 258,274 ----
<application>pg_dumpall</application> will need to connect several
times to the <productname>PostgreSQL</productname> server. If password
authentication is configured, it will ask for a password each time. In
! that case it would be convenient to set up a <filename>.pgpass</>
! password file.
! </para>
!
! <para>
! Once restored, it is wise to run <command>ANALYZE</> on each
! database so the optimizer has useful statistics. You
! can also run <command>vacuumdb -a -z</> to <command>ANALYZE</> all
! databases.
</para>
</refsect1>
Index: doc/src/sgml/ref/pg_restore.sgml
===================================================================
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/pg_restore.sgml,v
retrieving revision 1.35
diff -c -c -r1.35 pg_restore.sgml
*** doc/src/sgml/ref/pg_restore.sgml 19 Jan 2003 00:13:31 -0000 1.35
--- doc/src/sgml/ref/pg_restore.sgml 17 Mar 2003 23:58:47 -0000
***************
*** 589,594 ****
--- 589,600 ----
See also the <xref linkend="app-pgdump"> documentation for details on
limitations of <application>pg_dump</application>.
</para>
+
+ <para>
+ Once restored, it is wise to run <command>ANALYZE</> on each
+ restored object so the optimizer has useful statistics.
+ </para>
+
</refsect1>
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
