Hi,
On 2022-02-19 22:38:19 +0900, Masahiko Sawada wrote:
> On Sat, Feb 19, 2022 at 5:32 AM Andres Freund <andres@anarazel.de> wrote:
> > 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.
That's precisely the misuse of the stats subsystem that I'm complaining about
here. The whole design of pgstat (as it is today) only makes sense if you can
loose a message and it doesn't matter much, because it's just an incremental
counter increment that's lost. And to be able properly prune dead pgstat
contents the underlying objects stats are kept around either need to be
permanent (e.g. stats about WAL) or a record of objects needs to exist
(e.g. stats about relations).
Even leaving everything else aside, a key of (dboid, subid, subrelid), where
subrelid can be NULL, but where (dboid, subid) is *not* unique, imo is poor
relational design. What is the justification for mixing relation specific and
non-relation specific contents in this view?
The patch you referenced [1] should just store the stats in the
pg_stat_subscription view, not pg_stat_subscription_workers.
It *does* make sense to keep stats about the number of table syncs that failed
etc. But that should be a counter in pg_stat_subscription, not a row in
pg_stat_subscription_workers.
IOW, we should just drop pg_stat_subscription_workers, and add a few counters
to pg_stat_subscription.
Greetings,
Andres Freund
[1]
https://www.postgresql.org/message-id/TYCPR01MB8373E658CEE48FE05505A120ED529%40TYCPR01MB8373.jpnprd01.prod.outlook.com