Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w7NUk-005FRT-0p for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2026 01:02:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w7NTi-007SW7-0j for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2026 01:01:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w7NTh-007SVz-2R for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2026 01:01:10 +0000 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w7NTa-00000001tNN-2I2t for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2026 01:01:09 +0000 Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-5a12cd0bcd8so3742914e87.3 for ; Mon, 30 Mar 2026 18:01:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774918861; cv=none; d=google.com; s=arc-20240605; b=TVJPDV+7G+pyu+aK+ijxQ+05aWvo2wI6CV42BAu+dZWe8t8Zky46yBLp8Q5BjRT41Z GhsAusg80/o1j7Y9p3CHvADkRJtorgomz0QQDRKy3LerV92Q927jOvq/6Qx+RYnH2WFP Qd4q+Kfr12hoG+6sjWNUHk7eTZOtIo3Neoi29K+5qqLV2CF6JAcLBsQ/QLpkRZmRb1hZ mujmwlKz0lwsJajjgQyEDXMbrfHSyLLU3UALG4M1zawgA+j9DZMNtA6o4Hl46CgUp3UU wUXTNoK1CLlSLwpcMA7eVEc11O3HKf5J22wZYStvTpCK4O8t5QqrLERgM1tha61uP+lD bczQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=5sz+AoG6wEHWA/1sPde7Yf/O9ATDnP+goPXIzDL6aIg=; fh=vzjNho8qjK1ph9iyx0CYu9UDeE0UqrDqKBlEXBAtwQU=; b=k5tH2e0vSpkCPck3gZXhBOev+IyCth2OVbpmm562WXY/VUzakHDIiHuS+oEix+Aotm XW0chkJZcj0EcTbqBP6bjQitJVH2mhZ19qRMIEF7H+dctVy87RJKWmlF8Vusb9NdARX3 2I7Rni0XU+iz96SwE9m05VFXOFOF7mPPPnFsoZPn9zz8G72kMdiaClkLKJ/465VNYd4K n58G32EG3lrEzNwNrtDtKPiUmg3j6nAv12yLOS6hYqwBU5z7dyBV4luG/8kq8EDYer1P GHNeAe9KfwUn8hmLyYmGvGrrElMgsfZMqkmB3j5j43DmuwcE5n2p4SzlklHOR1xeDjrT d1RQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774918861; x=1775523661; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5sz+AoG6wEHWA/1sPde7Yf/O9ATDnP+goPXIzDL6aIg=; b=Gf1POa5WbKseItSXI2tV0bVbW8xlUGnL8iuTnJ+KSmYhJsZ3fYv2atZ3BqiK36ppkL 45pOF3UAa3Z1edVw2ulvz/7rPNgSfk3ZLQdZ7yo2pJrKl3PYs/zFR/28HGOVz0vqTEAP Jq9MICzW+gdTuoNxfa5qE7DlnbhQ8RFHUSj3UUP3tYeKixtKUqoDo/aKiIh6kDghLsmh mBcof9VnQ1Oc6M1cAmI1PJC22cOgZaWTWVAMZOh75Wna3FZcVGgE0GAwAwjUCELMYTrC Gts7/vBwyMQGKd7AEb2/ZC4CXvZEU/Xd85bq3V4LHsjHyWkEX1W5vmmPEmjd5wYVi9UL B8eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774918861; x=1775523661; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=5sz+AoG6wEHWA/1sPde7Yf/O9ATDnP+goPXIzDL6aIg=; b=rbtwlx2647VI4FSYbfhcojua4SehTDmM6IbjX5HUPw0f4j1cZCvweVgUCDLulQOPFY 1xRqLC7jnaZAXe6HpO8NjOm5sAHd64BCLrATuVIUtHz+KtbKijxY0eUc2ln2yG7hhrgi keJsLZAx93hGOygN3H1FRVrvja5RrhkYqz+LQcBnQ2e35Nxa7mYL44afEag1au34U4a5 St8E9+22ywn6L2Rbdx1W8Zo5Of84BSo3PGhtazDf7cYtxXsK4UypaGQHNjqwjsYJ8I5K ooc1u+bSxxwP5xdaOnDojiOh3Pu2YKHeG7ORm3Kya4eGT64fMr9VKUGeELmL81d4cS79 /+RQ== X-Forwarded-Encrypted: i=1; AJvYcCWW8gLehY3UPw12fodo+gD0rSM0kgZU/wGnqoFjLTw315vTCcu2Glme2Z2NjGVYEa8QyHs4amAPGjqx0xNn@lists.postgresql.org X-Gm-Message-State: AOJu0YxBMOQd7i9wES8i/c6+Vhv8q0qnRC5LFj+3TURxAjVN+CnJp9IC hVZzv6qoirAd8clHsZtQOq77FVko8Ed5Fxx+zisPTV4GzClY90FQ/lUZXBIeRsrKUZTO3XgbAsN W7eFXNkurt1FD4s1ge4tNp2hdfkaS0Jo= X-Gm-Gg: ATEYQzxMj9/QUDO0OK4u7QozMFNEdkd1CIOxjphRMt4dl2ljdE8nuXglmkVhWojamRt rYCL22xYRjO/e0jwEqi80XyLLp3qbZwI7RjWdgGMz4OlQiAzKE3FRUsR/MG9/yvtP4U8P/uFTZ0 ILomzCy90aSsAW7UtQnKkXOnH61EGQW9GQk+LX0AayKuE5LMG7dVchjjgiqUhj/ShbrIseqlGsu SGi6Wsi2g7YYq3eD/Fo+YElE8gkDOQb+2dgK/X2BgPYvG4HlHCSIki0UiuOBnpqIIEq1OI0Ni/1 tadVqzpmkjN/FlfpZWY= X-Received: by 2002:a05:6512:3b8d:b0:5a2:a70b:b2ca with SMTP id 2adb3069b0e04-5a2ab920a5emr4199180e87.23.1774918860374; Mon, 30 Mar 2026 18:01:00 -0700 (PDT) MIME-Version: 1.0 References: <0c28fbd1-3320-4e9b-815c-6d62753aa063@wi3ck.info> In-Reply-To: From: Masahiko Sawada Date: Mon, 30 Mar 2026 18:00:23 -0700 X-Gm-Features: AQROBzC1WlqkkLZQmRHJRLJApSwGrljiiVZdZliUwq0XKjKOG-e534iQn3hICFw Message-ID: Subject: Re: Initial COPY of Logical Replication is too slow To: "Hayato Kuroda (Fujitsu)" Cc: Amit Kapila , Jan Wieck , "pgsql-hackers@lists.postgresql.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Mar 30, 2026 at 12:42=E2=80=AFAM Hayato Kuroda (Fujitsu) 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 =3D get_rel_relkind(target_relid); > ``` > > Can we return here if the relkind is not RELKIND_RELATION nor RELKIND_PAR= TITIONED_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 !=3D NULL); > ``` > > Personally I prefer to do Assert() before the SRF_FIRSTCALL_INIT(). Becau= se 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 =3D> 'pg_get_publication_tables', prorows =3D> '10', > ``` > > Can prorows be 1? Because only a row would be returned here. > If multiple publications are specified, it could return more than one tuple= s. I'll submit the updated patch soon. Regards, --=20 Masahiko Sawada Amazon Web Services: https://aws.amazon.com