From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
Cc: | 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-02 22:27:06 |
Message-ID: | CAA5RZ0s920sAHXXcTpAOoY2cdzeFO7BEQUvpCXcsrOg7qT-OWQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> while working on relfilenode statistics [1], I observed that it's possible to call
> pg_stat_reset_single_table_counters() on a relation but the reset time is not
> reported in the related views.
>
> I think it's interesting to know when the stats have been reset, so the attached
> patch is adding stats_reset to the related views.
>
> Also, it's more consistent with other stat kinds that also report reset times.
+1. This field should clearly be there.
> This new field is not included into the pg_stat_xact_* views because the 0 values
> in transaction-local stats have nothing to do with reset operations.
>
> The patch is pretty straightforward, it:
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.
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?
--
Sami Imseih
Amazon Web Services (AWS)
From | Date | Subject | |
---|---|---|---|
Next Message | Alena Rybakina | 2025-10-02 22:42:38 | Re: MergeAppend could consider sorting cheapest child path |
Previous Message | David Rowley | 2025-10-02 22:24:45 | Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs |