From: | Keisuke Kuroda <keisuke(dot)kuroda(dot)3862(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables |
Date: | 2020-10-08 08:35:45 |
Message-ID: | CANDwggLfRF22WW_-fx1JaiGg4cdHPgieFsCo-N9hzT8i++nT8g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Dilip,
> I could not see this issue even without the patch, it is taking less
> than 1s even without the patch. See below results
>
> 2020-10-08 13:00:49 BEGIN 509
> 2020-10-08 13:00:49 table nsp_001.part_0001: INSERT:...
> 2020-10-08 13:00:49 COMMIT 509 (at 2020-10-08 13:00:48.741986+05:30)
>
> Am I missing something?
Thanks for running the tests.
It is the TRUNCATE decoding that takes time.
INSERT decoding is fast, even before the patch is applied.
2020-10-02 14:55:48 BEGIN 508
2020-10-02 14:55:48 table nsp_001.part_0001: INSERT ...
2020-10-02 14:55:49 COMMIT 508 (at 2020-10-02 14:55:48.744019+09)
However, TRUNCATE decode is slow
and take 222s in my environment.
2020-10-02 14:55:50 BEGIN 509
2020-10-02 14:59:42 table nsp_001.tbl_001 ... ns p_001.part_1000:
TRUNCATE: (no-flags)
2020-10-02 14:59:42 COMMIT 509 (at 2020-10-02 14:55:50.349219+09)
This script will wait 10 seconds after INSERT exits
before executing TRUNCATE, please wait for it to run.
When TRUNCATE completes,
the walsender process should be at 100% CPU.
Best Regards,
--
Keisuke Kuroda
NTT Software Innovation Center
keisuke(dot)kuroda(dot)3862(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-10-08 08:37:17 | Fix typos in reorderbuffer.c |
Previous Message | Masahiko Sawada | 2020-10-08 08:24:52 | Re: Resetting spilled txn statistics in pg_stat_replication |