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

On Mon, Aug 10, 2026 at 08:46:29AM +0000, Bertrand Drouvot wrote:
> Thanks! I just had a look at the updated version and I can see that the findings
> reported above have been fixed.

Okay, put my mind into this first part, and done.

While on it, I have added the following SQL functions to get access to
all the valid index-level data, still these are not used in any of the
stats views but had fields accessible with the relation functions:
pg_stat_get_xact_idx_tuples_returned
pg_stat_get_xact_idx_blocks_fetched
pg_stat_get_xact_idx_blocks_hit

Note that they provided their data when queried for indexes, just
their data has never been exposed. These two ones are used for
indexes, on the contrary:
pg_stat_get_xact_idx_tuples_fetched
pg_stat_get_xact_idx_numscans

This puts in light a defect with the existing system views, at least
it seems so to me. For example, pg_stat_xact_all_tables has a
idx_tup_fetch, but no idx_tup_read equivalent, as we have in
pg_stat_all_indexes. Perhaps this could be useful in terms of more
xact-level metrics? Having all these functions is still required to
me, of course. Or we could have a pg_stat_xact_all_indexes.

As of HEAD the state of find_tabstat_entry() is still unbalanced.
Note that the second patch cleans up all that, with a new
find_relstat_entry_kind() for everything.

A second thing is find_tabstat_entry_kind(), where I still have left
the increments of tuples_inserted, tuples_updated and tuples_deleted
for indexes on HEAD. That's a waste, but patch 2 takes care of that,
so..

Remaining patch attached. What do you think?
--
Michael