Re: Initial COPY of Logical Replication is too slow

From: Ajin Cherian <itsajin(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Jan Wieck <jan(at)wi3ck(dot)info>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Initial COPY of Logical Replication is too slow
Date: 2026-03-24 06:54:09
Message-ID: CAFPTHDb9ZiXzSu0N_1naOqAfLPWMOQV=o+WpL_EBLc5_5PEWvw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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()

thanks,
Ajin Cherian
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-03-24 06:56:28 heapam_tuple_complete_speculative : remove unnecessary tuple fetch
Previous Message Kirill Reshke 2026-03-24 06:53:44 Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)