On Thu, Nov 13, 2025 at 7:17 PM Ajin Cherian <[email protected]> wrote: > > On Thu, Nov 13, 2025 at 8:49 AM Masahiko Sawada <[email protected]> wrote: > > > > On Mon, Nov 10, 2025 at 7:37 PM Ajin Cherian <[email protected]> wrote: > > > > > > On Tue, Nov 11, 2025 at 2:19 PM Amit Kapila <[email protected]> > > > wrote: > > > > > > > > In the commit message, you mentioned: "Performance tests show it's > > > > faster than the COPY (SELECT ...) TO variant as it avoids the > > > > overheads of query processing and sending results to the COPY TO > > > > command.". Can you share the performance data to substantiate this > > > > point? > > > > > > > > > > This was based on the tests done in the original thread [1] and [2] > > > > Thank you for working on this item. I think it's a good follow-up > > patch for commit 4bea91f. > > > > Have you conducted any performance tests with logical replication > > setup? I've measured normal COPY TO cases but I think it would be > > worth checking how much the performance increase we can see in logical > > replication setup too. > > > Thanks for your interest in this patch. > I've tested the same setup as mentioned in [1] but with 10 tables and > 500 records each and measuring the total time it would take for all > the tablesync workers to finish sync (from log timings). > On the average: > Without patch > Tablesync time: 185.4 ms > Average COPY command times: 1.4168 ms > > With patch > Tablesync time: 172.2 ms (7% improvement) > Average COPY command times: 0.633 ms > > The improvement in performance is smaller as the table size increases. > There is better improvement for smaller tables. > Attaching my test scripts as well. >
Thank you for the test! I've also done some performance tests and got similar results. The patch is pretty simple and looks good to me. I'll push the patch, barring objections. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
