On Thu, Jun 16, 2016 at 04:45:14PM +0200, Magnus Hagander wrote:
> On Thu, Jun 16, 2016 at 4:35 PM, Euler Taveira <[email protected]> wrote:
>
> On 16-06-2016 09:05, Magnus Hagander wrote:
> > Shouldn't pg_upgrade turn off vacuum cost delay when it vacuums the new
> > cluster? Not talking about the post-analyze script, but when it runs
> > vacuumdb to analyze and freeze before loading the new schema, in
> > prepare_new_cluster()? Those run during downtime, so it seems like you'd
> > want those to run as fast as possible.
> >
> Doesn't --new-options do the job?
>
>
> You could, but it seems like it should do it by default.
Based on this seven year old post, I realized there are minimal
directions in pg_upgrade docs about how to generate statistics quickly,
so I created this patch to help.
We do have docs on updating planner statistics:
https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-STATISTICS
but that doesn't seem to cover cases where you are doing an upgrade or
pg_dump restore. Should I move this information into there instead?
--
Bruce Momjian <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
index 4f78e0e1c0..c72e69bb67 100644
--- a/doc/src/sgml/ref/pgupgrade.sgml
+++ b/doc/src/sgml/ref/pgupgrade.sgml
@@ -784,6 +784,14 @@ psql --username=postgres --file=script.sql postgres
of the upgrade. You might need to set connection parameters to
match your new cluster.
</para>
+
+ <para>
+ Using <command>vacuumdb --all --analyze-only</command> can efficiently
+ generate such statistics, and the use of <option>--jobs</option>
+ can speed it up. Option <option>--analyze-in-stages</option> can
+ be used to generate minimal statistics quickly. Non-zero values of
+ <varname>vacuum_cost_delay</varname> will delay statistics generation.
+ </para>
</step>
<step>
