Re: Add stats_reset to pg_stat_all_tables|indexes and related views

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add stats_reset to pg_stat_all_tables|indexes and related views
Date: 2025-10-03 01:24:39
Message-ID: aN8l182jKxEq1h9f@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Sabino Mullane 2025-10-03 02:23:22 Re: POC: Carefully exposing information without authentication
Previous Message Tatsuo Ishii 2025-10-03 01:06:06 Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options