Re: Initial COPY of Logical Replication is too slow

On Mon, Mar 23, 2026 at 11:54 PM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
>
> On Thu, Mar 19, 2026 at 10:30 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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.
> >
>
> The patch looks like a good performance improvement. Some minor comments:
>
> 1. src/test/regress/expected/publication.out
>
> +-- Clean up
> +DROP FUNCTION test_gpt(text[], relname);
> +ERROR: type "relname" does not exist
>
> Cleanup actually fails. Second parameter should be text, not relname.
>
> 2. src/include/catalog/pg_proc.dat
>
> + proallargtypes => '{text,oid,oid,oid,int2vector,pg_node_tree}',
> + proargmodes => '{i,i,o,o,o,o}',
> + proargnames => '{pubname,relid,pubid,relid,attrs,qual}',
>
> Having two arguments with the same name "relid" seems odd, although
> one is input and other is output parameter, how about calling input
> parameter as target_relid?
>
> 3. src/backend/replication/logical/tablesync.c
>
> +
> + if (server_version >= 190000)
> + {
> + /*
> + * We can pass relid to pg_get_publication_table_info() since
> + * version 19.
> + */
> + appendStringInfo(&cmd,
> + "SELECT DISTINCT"
>
> In multiple places in the code pg_get_publication_table_info() is
> used, instead of pg_get_publication_tables()

Thank you for reviewing the patch! I agree with all the above points.
I'll share the updated patch soon.

Regards,

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