On Thu, Oct 02, 2025 at 05:27:06PM -0500, Sami Imseih wrote:
> +1. This field should clearly be there.
Yeah, Bertrand has mentioned this one to me offlist, and I was equally
surprised by the field gone missing.
One question would be if we need to worry about the additional bytes
of this field, but seeing the size of PgStat_StatTabEntry currently
I'm going to answer "no" to my own question in advance.
> Nothing jumped out at me in the code. Although, I think we should add
> at least one test where pg_stat_reset_single_table_counters() is called
> with an index OID. There isn't a difference in the way the stats are
> reset for indexes and tables, but they are presented in different views,
> so it makes sense to add test coverage.
Makes sense to me. This matters in terms of coverage for HEAD,
being outside of the scope of this proposal.
> On a side note: I really think pg_stat_reset_single_table_counters is
> the wrong name here, since other OIDs can be used here; indexes
> or materialized views, etc. Maybe pg_stat_reset_single_relation_counters
> will be better?
It's mostly a historical artifact at this stage, and the function is
documented as being usable for an index or a table. Using "relation"
would be more consistent, indeed. I am not sure if it's worth
bothering, though.
What's the point of having tests for two tables? Shouldn't the one
based on test_last_scan be enough? The one on pg_shdescription may
actually fail on repeated runs, may it not? It is a shared catalog.
--
Michael
