On Sat, Feb 19, 2022 at 9:02 AM Andres Freund <andres@anarazel.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.
