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
signature.asc
Description: PGP signature
