Re: Initial COPY of Logical Replication is too slow - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Initial COPY of Logical Replication is too slow
Date
Msg-id CAA4eK1Jkouj=w+PHzMB6v890ES3QOLf=cUTvZmGFr-WMQW2OnA@mail.gmail.com
Whole thread
In response to Re: Initial COPY of Logical Replication is too slow  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Initial COPY of Logical Replication is too slow
List pgsql-hackers
On Thu, Mar 19, 2026 at 4:59 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Mar 18, 2026 at 3:31 PM Masahiko Sawada <sawada.mshk@gmail.com> 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.
>

*
+ /*
+ * We can pass relid to pg_get_publication_table_info() since
+ * version 19.
+ */
+ appendStringInfo(&cmd,
+ "SELECT DISTINCT"
+ "  (CASE WHEN (array_length(gpt.attrs, 1) = c.relnatts)"
+ "   THEN NULL ELSE gpt.attrs END)"
+ "  FROM pg_publication p,"
+ "  LATERAL pg_get_publication_tables(p.pubname, %u) gpt,"
+ "  pg_class c"
+ " WHERE c.oid = gpt.relid"
+ "   AND p.pubname IN ( %s )",
+ lrel->remoteid,
+ pub_names->data);

Why in the above query we need a join with pg_publication? Can't we
directly pass 'pub_names' and 'relid' to pg_get_publication_tables()
to get the required information?


--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: TupleDescAttr bounds checks
Next
From: Hannu Krosing
Date:
Subject: Re: SQL Property Graph Queries (SQL/PGQ)