Re: Enhance statistics reset functions to return reset timestamp

On Sat, 9 Aug 2025 at 10:38, Andres Freund <andres(at)anarazel(dot)de> 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.