On Wed, Mar 23, 2022 at 8:55 PM Andres Freund <and...@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
