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

From Peter Eisentraut
Subject Re: Design of pg_stat_subscription_workers vs pgstats
Date
Msg-id ca9f44f0-a553-2f57-8017-d0ad84e06a6a@enterprisedb.com
Whole thread Raw
In response to Re: Design of pg_stat_subscription_workers vs pgstats  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Design of pg_stat_subscription_workers vs pgstats  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: Design of pg_stat_subscription_workers vs pgstats  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 24.02.22 12:46, Masahiko Sawada wrote:
>> We have a view called pg_stat_activity, which is very well known.  From
>> that perspective, "activity" means what is happening right now or what
>> has happened most recently.  The reworked view in this patch does not
>> contain that (we already have pg_stat_subscription for that), but it
>> contains accumulated counters.
> Right.
> 
> What pg_stat_subscription shows is rather suitable for the name
> pg_stat_subscription_activity than the reworked view. But switching
> these names would also not be a good idea.  I think it's better to use
> "subscription" in the view name since it shows actually statistics for
> subscriptions and subscription OID is the key. I personally prefer
> pg_stat_subscription_counters among the ideas that have been proposed
> so far, but I'd like to hear opinions and votes.

_counters will fail if there is something not a counter (such as 
last-timestamp-of-something).

Earlier, pg_stat_subscription_stats was mentioned, which doesn't have 
that problem.



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: convert libpq uri-regress tests to tap test
Next
From: Peter Eisentraut
Date:
Subject: Re: convert libpq uri-regress tests to tap test