On Tue, Aug 18, 2026 at 10:50:48PM -0500, Sami Imseih wrote: >> FWIW, I'd vote for an helper comparing the five counters that can be >> flushed immediately. There are only five, and adding another one would >> already require updating the merge and baseline logic. >> >> That would keep the policy local to pgstat_relation_flush_cb() and avoid >> making PgStat_TableCounts field order part of the flush logic. > > Fair point. > > I was looking at it less as a one-off fix here and more as a reusable approach > for kinds that mix the two. I'd rather not end up with a > field-by-field compare in > every flush callback, and just keep it a single memcmp(). I went with grouping > the counters and comparing by offset mainly because it was the least > friction to > get there, although not the cleanest. > > What about splitting the transaction-safe and non-transaction-safe counters > into two nested structs inside PgStat_TableCounts? That puts the boundary in > the type instead of an offset, and each group is still one memcmp().
I agree that splitting the transaction and non-transactional parts of PgStat_TableCounts, backend-level pending stats data for relations would make sense. I was wondering about the interactions with transactional flushes last week when splitting the relation and index stats, with a single memcmp() not feeling like the best fit for the job. Two memcmp() would feel better if we pass a transactional flag to the flush callbacks. It seems to me that you don't need two nested structures inside PgStat_TableCounts (if that's what you mean?), but you could just have a new piece for the transactional data in PgStat_RelationStatus when dealing with a PGSTAT_KIND_RELATION? That feels simple enough as an independent piece of refactoring, at quick glance. >> That said, let's see what Michael thinks. > > +1 Both of you are putting too much pressure on my shoulders. :) -- Michael
signature.asc
Description: PGP signature
