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.
