On Fri, Dec 10, 2021 at 6:24 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> I just noticed that this (commit 5a2832465fd8) added a separate catalog
> to store schemas which are part of a publication, side-by-side with the
> catalog to store relations which are part of a publication. This seems
> a strange way to represent publication membership: in order to find out
> what objects are members of a publication, you have to scan both
> pg_publication_rel and pg_publication_namespace. Wouldn't it make more
> sense to have a single catalog for both things, maybe something like
>
> pg_publication_object
> oid OID -- unique key (for pg_depend)
> prpubid OID -- of pg_publication
> prrelid OID -- OID of relation, or 0 if not a relation
> prnspid OID -- OID of namespace, or 0 if not a namespace
>
> which seems more natural to me, and pollutes the system less with weird
> syscaches, etc.
>
It will unnecessarily increase the size per row for FOR TABLE
publication both because of the additional column and additional index
(schema_id, pub_id) and vice versa. I think future projects (like
row_filter, column_filter, etc) will make this impact much bigger as
new columns for those won't be required for schema publications.
Basically, as soon as we start to store additional properties for
different objects, storing different objects together would start
becoming more and more worse. This will also in turn increase the scan
cost where we need only schema or rel publication access like where
ever we are using PUBLICATIONNAMESPACEMAP. I think it will increase
the cost of scanning table publications as its corresponding index
will be larger.
--
With Regards,
Amit Kapila.