MIME-Version: 1.0
References: 
 <CAB-JLwbBFNuASyEnZWP0Tck9uNkthBZqi6WoXNevUT6+mV8XmA@mail.gmail.com>
 <CAD21AoA6i2ui8FMZeuU_KxX4t-fM8G==zTW2Dp6-goujttrpew@mail.gmail.com>
 <CAB-JLwZpp=7c9_r0beWWJxRh2BS_2Vvth8UDv7H57DBeaqggVg@mail.gmail.com>
 <CAD21AoDT3sL2COprsRumM9zEpL1Bk5VWboK4V2mRnjGua8xfeA@mail.gmail.com>
 <CAD21AoDQM62GOtaTzD_CVMSsFhv6o9c0Au1dSM1QuxeKFkWAKw@mail.gmail.com>
 <CAD21AoCz7HjEr3oeb=haK31YHxHZLcvD_wx_a-+xLPKywq++3A@mail.gmail.com>
 <TY4PR01MB16907733B75A99117F013AFCA947FA@TY4PR01MB16907.jpnprd01.prod.outlook.com>
 <CAD21AoA9YgiY1rVKMPZwB00WU_G4UfzoawY=7hyd7hpvBPcK6w@mail.gmail.com>
 <CAA4eK1KoSi60dtakJzn0MxNnHF1Yf4indSAffTjJxQG_31jsgQ@mail.gmail.com>
 <CAD21AoB4B3MOxJ7-v9YLjV5fTOtaLRUhX3jN3kqhEi7D7-uY4A@mail.gmail.com>
 <0c28fbd1-3320-4e9b-815c-6d62753aa063@wi3ck.info>
 <CAD21AoCmHpKrNg9D3mcOA973CZ5N_dBLxb8pERpSxEeRLSQxpA@mail.gmail.com>
 <CAD21AoAEVyxwn_bMWHvcU-Gcz3aUVjAtMbdgfoJ8MZNiLLEh0g@mail.gmail.com>
 <CAA4eK1Jkouj=w+PHzMB6v890ES3QOLf=cUTvZmGFr-WMQW2OnA@mail.gmail.com>
In-Reply-To: 
 <CAA4eK1Jkouj=w+PHzMB6v890ES3QOLf=cUTvZmGFr-WMQW2OnA@mail.gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Tue, 24 Mar 2026 11:57:50 -0700
Message-ID: 
 <CAD21AoB4_n7+s=uM9apX1JVtvGvgM8ismAx_uMxvDmUXfQULsw@mail.gmail.com>
Subject: Re: Initial COPY of Logical Replication is too slow
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Jan Wieck <jan@wi3ck.info>, pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAD21AoB4_n7%2Bs%3DuM9apX1JVtvGvgM8ismAx_uMxvDmUXfQULsw%40mail.gmail.com>
Precedence: bulk

On Tue, Mar 24, 2026 at 3:47=E2=80=AFAM Amit Kapila <amit.kapila16@gmail.co=
m> wrote:
>
> On Thu, Mar 19, 2026 at 4:59=E2=80=AFAM Masahiko Sawada <sawada.mshk@gmai=
l.com> wrote:
> >
> > On Wed, Mar 18, 2026 at 3:31=E2=80=AFPM Masahiko Sawada <sawada.mshk@gm=
ail.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) =3D 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 =3D 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?

Since the 'pub_names' is the list of publication names we cannot
directly pass it to the pg_get_publication_tables(). But if we make
pg_get_publication_tables() take {pubname text[], target_relid oid}
instead of {pubname text, target_relid oid}, yes. And it seems to help
somewhat simplify the patch. If having both
pg_get_publication_tables(VARIADIC text[]) and
pg_get_publication_tables(text[], oid) is not odd, it would be worth
trying it.

Regards,

--=20
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com