Re: Skipping schema changes in publication

From: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, YeXiu <1518981153(at)qq(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Skipping schema changes in publication
Date: 2026-02-16 12:41:16
Message-ID: CABdArM4KucFdHYPFCcpvpN7_OVnV5rpnDY7Daz7Cjn6ZuN-dkg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 16, 2026 at 8:50 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> Thanks for the comments, the attached v44 version patch has the
> changes for the same.
>
I’ve started reviewing/testing the patch. Few comments:

1) File - /doc/src/sgml/catalogs.sgml
if there is no publication qualifying condition.</para></entry>
</row>

+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>prexcept</structfield> <type>bool</type>
+ </para>

Should the column order in the doc match the order in
pg_publication_rel? In the table, the "prexcept" column appears before
"prqual", whereas in the doc it is listed after.

pg_publication.c: GetAllPublicationExcludedTables()
2) There may be a scope for optimization in how relids are processed.
Each time a new parentid is appended to the relids list, the first for
loop:

+ while (is_parent_in_except)
+ {
+ List *parentids = NIL;
+ List *curr = NIL;
+
+ foreach_oid(relid, relids) <<< this
+ {
+ Oid parentid;
+
+ if (!get_rel_relispartition(relid))
+ continue;
+

reprocesses all existing relids. Could we restrict it to check only
the newly added relids and avoid redundant work? Does this make sense?

I also feel the function would benefit from a few brief comments to
clarify the logic.

The attached file has the changes for the suggested optimization and
few comment suggestions for the function, if they seem suitable.

--
Thanks,
Nisha

Attachment Content-Type Size
nisha_v44_suggestion.txt text/plain 1014 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2026-02-16 13:05:01 Re: Refactoring postmaster's code to cleanup after child exit
Previous Message Álvaro Herrera 2026-02-16 12:36:07 Re: Improve docs syntax checking and enable it in the meson build