On Fri, Nov 24, 2023 at 01:10:01PM +0100, Michael Banck wrote:
> Hi,
>
> On Fri, Nov 24, 2023 at 12:17:56PM +0100, Magnus Hagander wrote:
> > On Fri, Nov 24, 2023 at 11:21 AM Michael Banck <mba...@gmx.net> wrote:
> > > On Wed, Nov 22, 2023 at 11:23:34PM -0500, Bruce Momjian wrote:
> > > > + Non-zero values of
> > > > + <varname>vacuum_cost_delay</varname> will delay statistics
> > > > generation.
> > >
> > > Now I wonder wheter vacuumdb maybe should have an option to explicitly
> > > force vacuum_cost_delay to 0 (I don't think it has?)?
> >
> > That's exactly what I proposed, isn't it? :)
>
> You're right, I somehow only saw your mail after I had already sent
> mine.
>
> To make up for this, I created a patch that implements our propoals, see
> attached.
This is already posssible with PGOPTIONS, so I don't see the need for
a separate option:
PGOPTIONS='-c vacuum_cost_delay=99' psql -c 'SHOW vacuum_cost_delay;'
test
vacuum_cost_delay
-------------------
99ms
(1 row)
Here is a patch which shows its usage.
--
Bruce Momjian <br...@momjian.us> 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..2520f6c50d 100644
--- a/doc/src/sgml/ref/pgupgrade.sgml
+++ b/doc/src/sgml/ref/pgupgrade.sgml
@@ -784,6 +784,17 @@ 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.
+ 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
+ vacuum_cost_delay=0' vacuumdb ...</literal>.
+ </para>
</step>
<step>
