Re: VACUUM/ANALYZE double-count the backend's own pending table stats

Hi Joao,

Thanks for testing both builds and for spelling out the coverage and
limitations. Yes, please send the scripts and output, particularly for
the TRUNCATE/SAVEPOINT and pg_stat_reset() cases.

On n_mod_since_analyze, 1300 is consistent with the current behavior,
since TRUNCATE does not reset that counter. Whether it should do so
was discussed in 2021 [1], with a patch to reset it and discussion of
whether that would delay a useful autoanalyze after TRUNCATE. I would
not treat this observation as a new bug or propose changing that policy
as part of this patch. It is distinct from losing a pending TRUNCATE
flag when a later transaction commits.

The 305 for n_ins_since_vacuum is also consistent with the existing
accounting of aborted inserts. pgstat_relation_flush_cb() uses
tuples_inserted for this counter and explicitly notes that it includes
aborted inserts. I'd like to see the exact SAVEPOINT placement before
relating that result to Manu's reproducers. It does not by itself show
the same problem.

The parent's zero counters are expected here too. Inserts are counted
on the leaf partitions, and ANALYZE of a partitioned parent explicitly
reports zero live/dead tuples to the cumulative stats system. The
parent's pg_class.reltuples estimate is maintained separately.

[1] https://www.postgresql.org/message-id/flat/CAD21AoAwdh5FqoVobm9qbQUR%3DtJjqnX8u5-d1RVFS1V%3DEexFMw%40mail.gmail.com

--
Ilya Staroverov