On 2014-01-14 22:22:08 -0500, Peter Eisentraut wrote:
> + <listitem>
> + <para>
> + Only calculate statistics for use by the optimizer (no vacuum),
> + like <option>--analyze-only</option>. Run several stages of analyze
> + with different configuration settings, to produce usable statistics
> + faster.
> + </para>
> +
> + <para>
> + This option is useful to analyze a database that was newly populated
> + from a restored dump or by <command>pg_upgrade</command>. This
> option
> + will try to create some statistics as fast as possible, to make the
> + database usable, and then produce full statistics in the subsequent
> + stages.
> + </para>
> + </listitem>
> + </varlistentry>
> +
If it's intended to be useful independent from pg_upgrade, shouldn't
this document in how many stages it runs?
> + const char *stage_commands[] = {
> + "SET default_statistics_target=1; SET
> vacuum_cost_delay=0;",
> + "SET default_statistics_target=10; RESET
> vacuum_cost_delay;",
> + "RESET default_statistics_target;"
> + };
> + const char *stage_messages[] = {
> + gettext_noop("Generating minimal optimizer statistics
> (1 target)"),
> + gettext_noop("Generating medium optimizer statistics
> (10 targets)"),
> + gettext_noop("Generating default (full) optimizer
> statistics (100 targets?)")
> + };
Imo 100 shouldn't be listed here, as it's actually using the database's
default.
This whole thing won't work for relations with per-column statistics
targets btw...
Other than that, it looks fine to me. And certainly nicer than that
chain of shell/bat pg_upgrade used to output.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
