Re: vacuumdb changes for stats import/export

On 7/26/25 21:38, Corey Huinker wrote:
>
>
> It is transactional, mostly.
>
> The attribute stats for the table being analyzed and all attribute stats
> for the dependent indexes that have at least one expression column, plus
> extended stats objects on that table, will be replaced in one atomic
> operation. The old stats were there, commit happens, now the new stats
> are there.
>
> The relation stats (pg_class) happen in-place, non-transactionally. So
> if you had an analyze that got canceled, and some of the relstats had
> been updated on the table or indexes, those would stay as-is.
>

Then it seems very unlikely that the query optimizer's choices become
transiently worse because of that, doesn't it? and this shouldn't be
used to justify this option, IMHO.

How about this? "This option is primarily intended to be used in
post-upgrade scripts to quickly generate minimal optimizer statistics"

> Having said all that, these are very nitpick details that may not need
> to be in our documentation.
>

+1

I've always supposed that the statistics were completely transactional,
I think most users do, and the difference with reality seems small enough.

>
>
>
> /me dons Hat of Pedantry (+2 against simple explanations)
>
> "Specifying this option then limits the result to only tables that are
> missing an attribute statistic, have an index that is missing an
> attribute statistic, or have an extended statistics object that is
> itself missing object statistics".
>
> /me removes hat
>
> "Specifying this option then limits the result to only those tables that
> do not already have complete statistics."
>
> The above phrase is asking the word "complete" to do a lot of heavy
> lifting, covering the dependent indexes and extended statistics objects.
> Specifying "table" makes it clear that any deficit in statistics results
> in the table getting analyzed, not just the single index or extended object.

FWIW I much prefer the last, simple phrase.