On Mon, Mar 23, 2026 at 5:54 PM Bharath Rupireddy <[email protected]> wrote: > > Hi, > > On Wed, Mar 18, 2026 at 4:29 PM Masahiko Sawada <[email protected]> wrote: > > > > I've attached the patch to implement this idea. The patch still > > introduces a new function but it overloads > > pg_get_publication_tables(). We might be able to handle different > > input (array or text) in pg_get_publication_tables() better, but it's > > enough for discussion at least. > > Overall, the intent of this patch looks good to me. It avoids the cost > of the table sync worker querying all the pg_publication_rel tables to > filter them out later in the join. > > I quickly reviewed the patch and here are some comments:
Thank you for reviewing the patch! > > 1/ Typo: s/pg_get_publication_table_info/pg_get_publication_tables Fixed. > > 2/ I think it's good to have some quick numbers on how the query > latency looks for pre-V19 and the new one that the table sync worker > executes on the publisher, say, with 100, 1000, and 10000 tables at > least. You can refer to the performance test results that I previously shared[1]. The patch I used was somewhat different from the current patch but the performance trend should be similar as the both are using the same approach. > > 3/ + Assert(OidIsValid(target_relid)); > > Why not error out (by treating it as function input parameter > validation) when target_relid is invalid because asserts go unnoticed > on production systems? Agreed. It would return no row if the specified relid is invalid or there is no corresponding table. I'll share the updated patch soon. Regards, [1] https://www.postgresql.org/message-id/CAD21AoDQM62GOtaTzD_CVMSsFhv6o9c0Au1dSM1QuxeKFkWAKw%40mail.gmail.com -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
