On Sat, 9 Aug 2025 at 10:38, Andres Freund <[email protected]> wrote: > On 2025-08-08 13:18:39 +0900, Shinya Kato wrote: > > I would like to propose a series of patches that enhance the behavior > > of various statistics reset functions by making them return the reset > > timestamp. This change improves usability and aligns with the behavior > > introduced in commit dc9f8a798[1], where pg_stat_statements_reset() > > was updated to return the reset time. > > > > The following functions have been modified to return a TIMESTAMP WITH > > TIME ZONE value indicating when the statistics were reset:
> -1 - I think it was a mistake to introduce support for granular resets, we > shouldn't bury ourselves deeper. If anything we should rip out everything > other than 1) a global reset b) a per-database reset. > > Leaving that aside, I just don't see a convincing use case for returning the > timestamp here. I agree with Andres here. Resetting the statistics for the purpose of tracking what's happened since last reset is just a mistake and it can even be dangerous when you consider autovacuum is driven from the PgStat_StatTabEntry stats. The race-condition free way of doing this is to log the values and subtract the previous value from the current one. That's pretty easy to do in Postgres with the LAG() window function. You don't need this feature to do that, so -1 from me. David.
