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

From Masahiko Sawada
Subject Re: Design of pg_stat_subscription_workers vs pgstats
Date
Msg-id CAD21AoDTO3bJvrc39Tv3VCeyUzZpimXnJuRhHQhKyjOWorHeOA@mail.gmail.com
Whole thread Raw
In response to Re: Design of pg_stat_subscription_workers vs pgstats  (Andres Freund <andres@anarazel.de>)
Responses Re: Design of pg_stat_subscription_workers vs pgstats  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sat, Feb 19, 2022 at 5:32 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2022-02-18 17:26:04 +0900, Masahiko Sawada wrote:
> > With this change, pg_stat_subscription_workers will be like:
> >
> > * subid
> > * subname
> > * subrelid
> > * error_count
> > * last_error_timestamp
>
> > This view will be extended by adding transaction statistics proposed
> > on another thread[1].
>
> I do not agree with these bits. What's the point of these per-relation stats
> at this poitns.  You're just duplicating the normal relation pg_stats here.
>
> I really think we just should drop pg_stat_subscription_workers. Even if we
> don't, we definitely should rename it, because it still isn't meaningfully
> about workers.

The view has stats per subscription worker (i.e., apply worker and
tablesync worker), not per relation. The subrelid is OID of the
relation that the tablesync worker is synchronizing. For the stats of
apply workers, it is null.

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Design of pg_stat_subscription_workers vs pgstats
Next
From: Amit Kapila
Date:
Subject: Re: Design of pg_stat_subscription_workers vs pgstats