Re: Initial COPY of Logical Replication is too slow

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Jan Wieck <jan(at)wi3ck(dot)info>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Initial COPY of Logical Replication is too slow
Date: 2026-03-31 01:00:23
Message-ID: CAD21AoBXwt1SvigufcORRtxBpavWuc5HZagpAejiMgzVZ0xW8Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 30, 2026 at 12:42 AM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Dear Sawada-san,
>
> Thanks for updating the patch. I think the patch has a good shape.
> Below contains minor comments.

Thank you for the comments!

>
>
> ```
> + if (filter_by_relid)
> + relkind = get_rel_relkind(target_relid);
> ```
>
> Can we return here if the relkind is not RELKIND_RELATION nor RELKIND_PARTITIONED_TABLE?
> Key assumption here is that pg_get_publication_tables_b() returns at most one
> tuple, thus this is would be called only once.

Yeah, I refactored these logic and do the preliminary check before
checking the publications.

>
> ```
> + /*
> + * Non-alltables
> + */
> + if (relispartition)
> ```
>
> else-if might be usalbe to clarify we're in the non-alltables case.

Hmm, we have the return statement at the end of the if branch so we
don't necessarily need else-if. Adding a new line after the comment
might help readability.

>
> ```
> + Assert(pubnames != NULL);
> ```
>
> Personally I prefer to do Assert() before the SRF_FIRSTCALL_INIT(). Because it's
> only related with argument and not related with other function calls.

If we move it before the SRF_FIRSTCALL_INIT(), we would end up
executing the assertion every time we call
pg_get_publication_table_b() since it could return more than one
tuple, which seems unnecessary to me. I think we can remove this
assertion because both _a() and _b() are strict functions.

>
> ```
> + proname => 'pg_get_publication_tables', prorows => '10',
> ```
>
> Can prorows be 1? Because only a row would be returned here.
>

If multiple publications are specified, it could return more than one tuples.

I'll submit the updated patch soon.

Regards,

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2026-03-31 01:09:47 Re: heapam_tuple_complete_speculative : remove unnecessary tuple fetch
Previous Message Peter Smith 2026-03-31 00:29:39 Re: Skipping schema changes in publication