| From: | "Zechman, Derek S" <Derek(dot)S(dot)Zechman(at)snapon(dot)com> |
|---|---|
| To: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: analyze-in-stages post upgrade questions |
| Date: | 2025-06-28 01:11:19 |
| Message-ID: | PH0PR04MB829491D78009BB616BF1880CC044A@PH0PR04MB8294.namprd04.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
We recently performed an upgrade from pg14 (14.18) to pg16 (16.9) and performed the analyze-in-stages post upgrade. It has been noticed that some plans changed to use hash joins instead of nested loops. Further investigation found it was because the parent table of partitioned tables did not have stats. After running an ANALYZE on the parent tables we got similar plan an execution times as before.
I have two questions
1 - Why does analyze-in-stages not analyze the parent tables?
2 – What happens if we do not run analyze-in-stages post upgrade and just run an analyze?
“It takes more time, and you don't have any statistics on a given table until the ANALYZE on that table completes.
How long did "vacuumdb --analyze-only --jobs=$mumble your_db" take?”
Thanks – that makes sense. I understand what analyze in stages does just wish it would include parent tables.
"vacuumdb --all --analyze-only --jobs=7" took about 75 minutes where the analyze-in-stages after upgrade took 115 minutes. Neither of these activities analyzed the parent tables.
Reading more and it seems vacuumdb doesn’t analyze parent tables and a manual analyze on those is needed if we want better planner statistics.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zechman, Derek S | 2025-06-28 01:23:59 | RE: analyze-in-stages post upgrade questions |
| Previous Message | Laurenz Albe | 2025-06-27 21:39:17 | Re: analyze-in-stages post upgrade questions |