On Wed, Mar 23, 2022 at 8:55 PM Andres Freund <andres@anarazel.de> wrote:
> This behaviour can be trivially (and is) implemented for the shared memory
> stats patch. But every time I read over that part of the code it feels just
> profoundly wrong to me. Way worse than *not* resetting
> pg_stat_database.stats_reset.
>
> Anybody that uses the time since the stats reset as part of a calculation of
> transactions / sec, reads / sec or such will get completely bogus results
> after a call to pg_stat_reset_single_table_counters().
Sure, but that's unavoidable anyway. If some stats have been reset and
other stats have not, you can't calculate a meaningful average over
time unless you have a specific reset time for each statistic.
To me, the current behavior feels more correct than what you propose.
Imagine for example that you are looking for tables/indexes where the
counters are 0 as a way of finding unused objects. If you know that no
counters have been zeroed in a long time, you know that this is
reliable. But under your proposal, there's no way to know this. All
you know is that the entire system wasn't reset, and therefore some of
the 0s that you are seeing might be for individual objects that were
reset.
I think of this mechanism like as answering the question "When's the
last time anybody tinkered with this thing by hand?". If it's recent,
the tinkering has a good chance of being related to whatever problem
I'm trying to solve. If it's not, it's probably unrelated.
--
Robert Haas
EDB: http://www.enterprisedb.com
