Re: Design of pg_stat_subscription_workers vs pgstats - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Design of pg_stat_subscription_workers vs pgstats
Date
Msg-id CAA4eK1LTKqMSjmi1_b=sGosjfjjcCQ9fkL0LOPWH4iR8k0A05g@mail.gmail.com
Whole thread Raw
In response to Re: Design of pg_stat_subscription_workers vs pgstats  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, Mar 2, 2022 at 1:26 PM Andres Freund <andres@anarazel.de> wrote:
>
> > > While rebasing, I was wondering why pgstat_reset_subscription_counter() has
> > > "all subscription counters" support. We don't have a function to reset all
> > > function stats or such either.
> > >
> >
> > We have similar thing for srlu (pg_stat_reset_slru) and slots
> > (pg_stat_reset_replication_slot).
>
> Neither should have been added imo. We're already at 9 different reset
> functions.
>

As per [1], we have 7.

>
> And having pg_stat_reset_shared() with variable
> 'reset' systems but then also pg_stat_reset_slru() and
> pg_stat_reset_subscription_stats() is absurd.
>

I don't know. I feel if for some subsystem, we have a way to reset a
single counter like for slru or slots, one would prefer to use the
same function to reset all stats of that subsytem. Now, for WAL,
bgwriter, etc., we don't want to reset any specific counter, so doing
it via a shared function is okay but not for others.

[1] - https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-STATS-FUNCTIONS

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Next
From: Wolfgang Walther
Date:
Subject: Re: [PATCH] Add reloption for views to enable RLS