Re: Design of pg_stat_subscription_workers vs pgstats

On Sat, Feb 19, 2022 at 9:02 AM Andres Freund <andres(at)anarazel(dot)de> wrote:

>
> 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 to-be-created pg_subscription_worker_error has this same design.
It really is a worker-oriented view so the PK should ideally (ignoring
dboid at the moment) be just workerid and subid and subrelid would just be
attributes, of which subrelid is optional. But a worker's natural key is
(subid, subrelid) so long as you accept that null has to be considered
equal to itself. Not usually an ideal model to pick but it seems like this
is one of those exceptions to the rule that works just fine. Feel free to
use InvalidOID instead of null if that makes things more consistent and
easier to implement. The conceptual model is still the same. It doesn't
seem to be beneficial to have tablesync and apply workers have their own
distinct relations. They are similar enough that they can share this one.

> IOW, we should just drop pg_stat_subscription_workers, and add a few
> counters
> to pg_stat_subscription.
>
>
+1
David J.