Re: analyze after a database restore?

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 <pgsql@mohawksoft.com> 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 majordomo@postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (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>