RE: analyze-in-stages post upgrade questions - Mailing list pgsql-general

From Zechman, Derek S
Subject RE: analyze-in-stages post upgrade questions
Date
Msg-id PH0PR04MB829491D78009BB616BF1880CC044A@PH0PR04MB8294.namprd04.prod.outlook.com
Whole thread Raw
In response to analyze-in-stages post upgrade questions  ("Zechman, Derek S" <Derek.S.Zechman@snapon.com>)
List 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.

pgsql-general by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: analyze-in-stages post upgrade questions
Next
From: "Zechman, Derek S"
Date:
Subject: RE: analyze-in-stages post upgrade questions