On Wed, Oct 01, 2025 at 02:33:11PM +0000, Bertrand Drouvot wrote:
> I think the first step is to replace (i.e get rid) PGSTAT_KIND_RELATION by a brand
> new PGSTAT_KIND_RELFILENODE and move all the existing stats that are currently
> under the PGSTAT_KIND_RELATION to this new PGSTAT_KIND_RELFILENODE.
Likely so, yes.
> Let's do this by keeping the pg_stat_all_tables|indexes and pg_statio_all_tables|indexes
> on top of the PGSTAT_KIND_RELFILENODE and ensure that a relation rewrite keeps
> those stats. Once done, we could work from there to add new stats (add writes
> counters and ensure that some counters (n_dead_tup and friends) are replicated).
Do you think it is OK to define non-transactional pending stats as
being always a subset of the transactional stats? I don't quite see
if there would be a case to have stats that are only flushed in a
non-transactional path, while being discarded at the stats report done
at transaction commit time. This means that it may be possible to
structure things so as the pending non-transaction stats structure are
always part of the transactional bits, and that the other way around
is not possible. Perhaps that influences the design choices, at least
a bit.
--
Michael
