Re: BUG #18046: stats collection behaviour change is affecting the usability of information.

At Wed, 6 Sep 2023 12:57:01 -0400, Bruce Momjian <bruce(at)momjian(dot)us> wrote in
> > Expected behaviour(works in all versions upto and including PostgreSQL 14)
> >
> >   datname  |          stats_reset          
> > -----------+-------------------------------
> >            | 2023-08-02 06:41:15.777135+00
> >  postgres  | 2023-08-02 06:41:15.777108+00
> >  template1 | 
> >  template0 | 
> >  db1       | 2023-08-02 11:02:54.954363+00
> > (5 rows)
> >
> >
> > The problem in PostgreSQL 15 and above
> >
> >   datname  |         stats_reset          
> > -----------+------------------------------
> >            | 
> >  postgres  | 
> >  db1       | 
> >  template1 | 
> >  template0 | 
> > (5 rows)

I agree it's not ideal to reset timestamps only for fixed-numbered
stats. In 13, the timestamp is set to the creation time. There's no
practical issue with doing it that way for now, I think it's
generallynot preferable.

We could use the transaction start time as a sufficient approximation
for the timestamp in fast paths. It might not align with with the
reset time set by pg_stat_reset(), but that shouldn't be a
problem. pgstat_restore_stats runs outside of a transaction, but
GetCurrentTimestamp() is already being used there. The reason for
defining a new function is to improve robustness, although it might
not be necessary.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center