diff options
| author | Nathan Bossart <nathan@postgresql.org> | 2025-04-30 14:12:59 -0500 |
|---|---|---|
| committer | Nathan Bossart <nathan@postgresql.org> | 2025-04-30 14:12:59 -0500 |
| commit | d5f1b6a75ba3f55a78959c957c3fd25d9569057c (patch) | |
| tree | 6480ed74f2bc1368c1cb0d23718f1d5188c81d21 | |
| parent | f60420cff66a9089a9b431f9c07f4a29aae4990a (diff) | |
| download | postgresql-d5f1b6a75ba3f55a78959c957c3fd25d9569057c.tar.gz postgresql-d5f1b6a75ba3f55a78959c957c3fd25d9569057c.zip | |
Further adjust guidance for running vacuumdb after pg_upgrade.
Since pg_upgrade does not transfer the cumulative statistics used
to trigger autovacuum and autoanalyze, the server may take much
longer than expected to process them post-upgrade. Currently, we
recommend analyzing only relations for which optimizer statistics
were not transferred by using the --analyze-in-stages and
--missing-stats-only options. This commit appends another
recommendation to analyze all relations to update the relevant
cumulative statistics by using the --analyze-only option. This is
similar to the recommendation for pg_stat_reset().
Reported-by: Christoph Berg <myon@debian.org>
Reviewed-by: Christoph Berg <myon@debian.org>
Discussion: https://postgr.es/m/aAfxfKC82B9NvJDj%40msg.df7cb.de
| -rw-r--r-- | doc/src/sgml/ref/pgupgrade.sgml | 12 | ||||
| -rw-r--r-- | src/bin/pg_upgrade/check.c | 9 |
2 files changed, 13 insertions, 8 deletions
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml index df13365b287..648c6e2967c 100644 --- a/doc/src/sgml/ref/pgupgrade.sgml +++ b/doc/src/sgml/ref/pgupgrade.sgml @@ -833,17 +833,19 @@ psql --username=postgres --file=script.sql postgres <para> Because not all statistics are not transferred by - <command>pg_upgrade</command>, you will be instructed to run a command to + <command>pg_upgrade</command>, you will be instructed to run commands to regenerate that information at the end of the upgrade. You might need to set connection parameters to match your new cluster. </para> <para> - Using <command>vacuumdb --all --analyze-only --missing-stats-only</command> - can efficiently generate such statistics. Alternatively, + First, use <command>vacuumdb --all --analyze-in-stages --missing-stats-only</command> - can be used to generate minimal statistics quickly. For either command, - the use of <option>--jobs</option> can speed it up. + to quickly generate minimal optimizer statistics for relations without + any. Then, use <command>vacuumdb --all --analyze-only</command> to ensure + all relations have updated cumulative statistics for triggering vacuum and + analyze. For both commands, the use of <option>--jobs</option> can speed + it up. If <varname>vacuum_cost_delay</varname> is set to a non-zero value, this can be overridden to speed up statistics generation using <envar>PGOPTIONS</envar>, e.g., <literal>PGOPTIONS='-c diff --git a/src/bin/pg_upgrade/check.c b/src/bin/pg_upgrade/check.c index 18c2d652bb6..940fc77fc2e 100644 --- a/src/bin/pg_upgrade/check.c +++ b/src/bin/pg_upgrade/check.c @@ -814,9 +814,12 @@ output_completion_banner(char *deletion_script_file_name) } pg_log(PG_REPORT, - "Some optimizer statistics may not have been transferred by pg_upgrade.\n" - "Once you start the new server, consider running:\n" - " %s/vacuumdb %s--all --analyze-in-stages --missing-stats-only", new_cluster.bindir, user_specification.data); + "Some statistics are not transferred by pg_upgrade.\n" + "Once you start the new server, consider running these two commands:\n" + " %s/vacuumdb %s--all --analyze-in-stages --missing-stats-only\n" + " %s/vacuumdb %s--all --analyze-only", + new_cluster.bindir, user_specification.data, + new_cluster.bindir, user_specification.data); if (deletion_script_file_name) pg_log(PG_REPORT, |