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>
 <CALj2ACUswwdgrp8U=_EBRCv9qUJD+YUEHwbSziB2TE99Hc4SvA@mail.gmail.com>
In-Reply-To: 
 <CALj2ACUswwdgrp8U=_EBRCv9qUJD+YUEHwbSziB2TE99Hc4SvA@mail.gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Tue, 24 Mar 2026 11:41:24 -0700
Message-ID: 
 <CAD21AoCEVN9=gAokQaxMhYav6TreHLLoo-8SyF4+4veFHteWug@mail.gmail.com>
Subject: Re: Initial COPY of Logical Replication is too slow
To: Bharath Rupireddy <bharath.rupireddyforpostgres@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/CAD21AoCEVN9%3DgAokQaxMhYav6TreHLLoo-8SyF4%2B4veFHteWug%40mail.gmail.com>
Precedence: bulk

On Mon, Mar 23, 2026 at 5:54=E2=80=AFPM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Hi,
>
> On Wed, Mar 18, 2026 at 4:29=E2=80=AFPM Masahiko Sawada <sawada.mshk@gmai=
l.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.
>
> 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_CVMSsFhv6o9c0=
Au1dSM1QuxeKFkWAKw%40mail.gmail.com

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