Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset

On Wed, Mar 30, 2022 at 1:39 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2022-03-30 12:29:51 -0700, David G. Johnston wrote:
> > On Wednesday, March 30, 2022, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > My current proposal is to just have two reset times. One for the
> contents
> > > of
> > > pg_stat_database (i.e. not affected by
> pg_stat_reset_single_*_counters()),
> > > and
> > > one for stats within the entire database.
>
> > What IS it affected by? And does whatever affects it affect anything
> else?
>
> pg_stat_reset() resets the current database's stats. That includes the
> database's row in pg_stat_database and all table and function stats.
>
>
Right, so basically it updates both of the fields you are talking about.

The existing stats_reset field is also updated upon
calling pg_stat_reset_single_*_counters()

So when the two fields are different we know that at least one relation or
function statistic row is out-of-sync with the rest of the database, we
just don't know which one(s). This is an improvement over the status quo
where the single timestamp cannot be trusted to mean anything useful. The
DBA can execute pg_stat_reset() to get the statistics back into a common
state.

As an added bonus we will always have a reference timestamp for when the
pg_stat_database database record was last reset (as well as any other
statistic record that can only be reset by using pg_stat_reset).

David J.