Re: Split index and table statistics into different types of stats

On Mon, Aug 10, 2026 at 04:40:54AM +0000, Bertrand Drouvot wrote:
> I had a look at 0001 only, and I've a few comments.

Thanks for the review.

> === 1
>
> +pgstat_index_flush_cb(PgStat_EntryRef *entry_ref, bool nowait)
> +{
> [...]
> + /* The entry was successfully flushed, add the same to database stats */
> + dbentry = pgstat_prep_database_pending(dboid);
> + dbentry->blocks_fetched += lstats->counts.blocks_fetched;
> + dbentry->blocks_hit += lstats->counts.blocks_hit;
>
> Shouldn't we add tuples_returned and tuples_fetched here too?

Argh. I have missed these two. Nice catch.

> === 2
> But it looks like that pg_stat_get_xact_numscans() descr has not been updated
> in pg_proc.dat although it now returns 0 for indexes.

Indeed. This needs to be updated. Done now in the attached.

A test could be in place here, I guess, but we cannot make it relevant
except in a TAP test where the counter increments would be isolated.
Will look at how possible this could be later. For now, I will do an
extra pass later on this patch. Updated version is attached for now.

> There is no public doc for pg_stat_get_numscans() and pg_stat_get_xact_numscans(),
> so existing callers will get different behavior (that is not publicly documented).
>
> Should we preserve the old behavior while keeping the new functions as explicit
> alternatives? Or is it less of an issue given that those 2 don't have public
> doc?

pg_stat_get_xact_numscans() is only called for
pg_stat_xact_all_tables. pg_stat_get_numscans() is only called for
pg_stat_all_tables. Both apply to relkind IN ('r', 't', 'm', 'p').
So returning 0 is not a big deal IMO. We have never used that for
indexes, and the table behavior is untouched. So I think that the
patch as-is looks fine on this side.
--
Michael