Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
Date
Msg-id 20220330005008.fmwvbkdhn456svhy@alap3.anarazel.de
Whole thread Raw
In response to Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
Hi,

On 2022-03-29 17:06:24 -0700, David G. Johnston wrote:
> On Tue, Mar 29, 2022 at 4:43 PM Andres Freund <andres@anarazel.de> wrote:
> > But more importantly, a
> > per-relation/function reset field wouldn't address Tomas's concern: He
> > wants a
> > single thing to check to see if any stats have been reset - and that's imo
> > a
> > quite reasonable desire.
> >
> 
> Per the original email:
> 
> "Starting with the below commit, pg_stat_reset_single_function_counters,
> pg_stat_reset_single_table_counters don't just reset the stats for the
> individual function, but also set pg_stat_database.stats_reset."
> 
> Thus we already have the desired behavior, it is just poorly documented.

The problem is that it also make stats_reset useless for other purposes -
which I do consider a problem. Hence this thread.  My concern would be
mollified if I there were a separate reset timestamp counting the last
"database wide" reset time. Your comment about that was something about
relation/function level timestamps, which doesn't seem relevant.


> Now, maybe other functions aren't doing this?  If so, given these functions
> do, we probably should just change any outliers to match.

Don't think there are other functions.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: pgsql: Add 'basebackup_to_shell' contrib module.
Next
From: "David G. Johnston"
Date:
Subject: Re: [PATCH] Full support for index LP_DEAD hint bits on standby