Re: pgstat: Flush some statistics within running transactions, take 2

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