Re: Skipping schema changes in publication - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: Skipping schema changes in publication
Date
Msg-id CAMMNXX=nFgcPc5_zes3MU7kwuCx8xsuBDHVBYF6LCsT1kHU_Nw@mail.gmail.com
Whole thread
In response to Re: Skipping schema changes in publication  (vignesh C <vignesh21@gmail.com>)
Responses Re: Skipping schema changes in publication
List pgsql-hackers
On 25/2/26 08:04, vignesh C wrote:
> On Mon, 23 Feb 2026 at 16:46, Amit Kapila <amit.kapila16@gmail.com> wrote:
> The attached patch has the changes for the same i.e.a) Raises an error
> when attempting to attach a partition to a root partitioned table if
> that table is referenced in an EXCEPT clause of any publication. b)
> Adds support for dropping excluded tables using: ALTER PUBLICATION ...
> DROP EXCEPT TABLE. c) Adds support for replacing the exclusion list
> using  ALTER PUBLICATION ... SET EXCEPT TABLE.
> The changes related to DROP EXCEPT TABLE and SET EXCEPT TABLE have
> been kept separately into patch 0002 for easier review.

I discovered this patch, maybe not deeply enough. But one question raised.

I usually work with multiple tables (sometimes hundreds, if not
thousands). EXCEPT clause might be quite rare. Some commands want to
extract only excepted tables from the publication using the following
pattern:

'SELECT ... FROM pg_publication_rel WHERE prpubid = <X> AND pr.prexcept'

- check_publications_except_list()
- describePublications()
- getPublications()
- LoadPublications() / publication_has_any_except_table()

That means pass through all the publication tables to find (usually)
nothing. It might be a costly operation, especially in the
LoadPublications routine. Maybe slightly change index
pg_publication_rel_prpubid_index a little and add 'prexcept' as a second
column there? It might avoid performance issues that may arise during
the upgrade.


--
regards, Andrei Lepikhov,
pgEdge



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Make use of unvolatize() in vac_truncate_clog()
Next
From: Zsolt Parragi
Date:
Subject: Re: Reduce planning time for large NOT IN lists containing NULL