Re: vacuumdb changes for stats import/export - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: vacuumdb changes for stats import/export
Date
Msg-id CAKFQuwYzgRbRBH6T+QZ=Cioy5rLB4mJDZUH2CjMebpFBDKuC_g@mail.gmail.com
Whole thread Raw
In response to Re: vacuumdb changes for stats import/export  (Frédéric Yhuel <frederic.yhuel@dalibo.com>)
Responses Re: vacuumdb changes for stats import/export
Re: vacuumdb changes for stats import/export
List pgsql-hackers
On Monday, July 28, 2025, Frédéric Yhuel <frederic.yhuel@dalibo.com> wrote:


On 7/28/25 16:47, Nathan Bossart wrote:
I can't remember who wrote this line, but it was borrowed from the
--analyze-in-stages description.  The point is that if you use
--analyze-in-stages without --missing-stats-only, there will be a period
where existing statistics will be replaced with ones generated with lower
statistics targets.

Aha, it makes sense now, thank you!

Obviously, this wording isn't clear enough.  We might
need to either remove that sentence or add "When used in conjunction with
--analyze-in-stages..."

I vote for the second option.


Makes sense.  This does beg the question - what happens if a column is left with a lower statistics target than what would be applied during an analyze, but one is present?  I don’t see where the statistics target is saved anywhere.  Can we start recording that piece of data and teach analyze in stages to just never go backwards - reporting any it had to skip to adhere to that rule.  Seems like a better policy than missing-only.

David J.
 

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Support getrandom() for pg_strong_random() source
Next
From: Andrey Borodin
Date:
Subject: Re: MultiXact\SLRU buffers configuration