public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ron Johnson <[email protected]>
To: pgsql-general <[email protected]>
Subject: Re: Help in vetting outcome of "vacuumdb --analyze-in-stages" - during DB Upgrade from EC2- PGS - Community Edn ver 13.X to 14.X
Date: Sun, 16 Feb 2025 09:35:41 -0500
Message-ID: <CANzqJaAN0=i9RS3yjc-p5TpJYV876d=BmC_7ita0RnOzs0dBPA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CANzqJaC1Uk4H=55vV_jbFYMuD1f9Bb_4Y9WKvkZA3bt92bEUnw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAKAnmmKZdhnhdNRd3OgDyEco9OPkT=qA_TeWMFMRvUM9pXauKg@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
On Sun, Feb 16, 2025 at 8:13 AM Y_Bharani_mbsv <[email protected]> wrote:
> Team
> Good Morning.
> As part of DB upgrade from EC2 - PGS - community Edn Ver 13.X to 14.X
> I followed steps of "pg_upgrade" and had executed the last step (post
> successful db migration)
>
> vacuumdb --analyze-in-stages
>
> and later noticed an caveat
> url = https://www.postgresql.org/docs/current/app-vacuumdb.html
>
>
> --analyze-in-stages
>
> Only calculate statistics for use by the optimizer (no vacuum), like
> --analyze-only. Run three stages of analyze; the first stage uses the
> lowest possible statistics target (see default_statistics_target
> <https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET;)
> to produce usable statistics faster, and subsequent stages build the full
> statistics.
>
> This option is only useful to analyze a database that currently has no
> statistics or has wholly incorrect ones, such as if it is newly populated
> from a restored dump or by pg_upgrade. *Be aware that running with this
> option in a database with existing statistics may cause the query optimizer
> choices to become transiently worse due to the low statistics targets of
> the early stages.*
>
> How to overcome the issue to avoid "transiently worse"
>
"Transiently" means "temporarily".
And since pg_upgrade does not carry over optimizer statistics, query
optimizer choices would be transiently worse *anyway* until the ANALYZE
completes.
> Later, I too did
> a) vacuum(full,verbose,skip_locked) ... each table wise
>
Why? It certainly didn't do what you think it did.
(This is why giving "rewrite the whole table" the name VACUUM FULL was a
horrible idea.)
> b) analyze (verbose,skip_locked) .. each table wise
> Any guidance
>
You wasted much time and effort. Best to have just waited until
the --analyze-in-stages had completed.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
view thread (61+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected]
Subject: Re: Help in vetting outcome of "vacuumdb --analyze-in-stages" - during DB Upgrade from EC2- PGS - Community Edn ver 13.X to 14.X
In-Reply-To: <CANzqJaAN0=i9RS3yjc-p5TpJYV876d=BmC_7ita0RnOzs0dBPA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox