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. regards, Ajin Cherian Fujitsu Australia [1] - https://www.postgresql.org/message-id/174219852967.294107.6195385625494034792.pgcf%40coridan.postgresql.org
log_analyzer_functions.sh
Description: Binary data
test-tablesync-perf-v4.sh
Description: Binary data
