On Mon, Oct 27, 2025 at 12:50 PM David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Sat, 9 Aug 2025 at 10:38, Andres Freund <andres@anarazel.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.
Okay, since there are some objections, I will withdraw these patches.
Thank you all for your comments.
--
Best regards,
Shinya Kato
NTT OSS Center
