Postgres Pro
Downloads
Home   >   mailing lists

Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables - Mailing list pgsql-hackers

From Keisuke Kuroda
Subject Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Date
Msg-id CANDwggLd7s-qRPTxQFoN6vCvnh5Hj_DM4OT8GnvGN5BxMptzWA@mail.gmail.com
Whole thread Raw
In response to Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Tree view 
Hi Dilip, Amit,

Thank you for the patch!

I test the patch on the master HEAD(9796f455) and it works fine.
* make installcheck-world: passed
* walsender process continues to use 100% of the CPU 1core when
TRUNCATE 1000 partition: 1s or less
** before patch : 230s

There is "ReorderBufferAddInvalidation" in reorderbuffer.h, but I
don't think it's needed.

src/include/replication/reorderbuffer.h
+void ReorderBufferAddInvalidation(ReorderBuffer *, TransactionId,
XLogRecPtr lsn,
+                 int nmsgs, SharedInvalidationMessage *msgs);

If possible, I'd like to improve it even before PG13,
 but I recognize that it's difficult because it uses a PG14 or later
mechanism...

Best Regards,
-- 
Keisuke Kuroda
NTT Software Innovation Center
keisuke.kuroda.3862@gmail.com

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Disable WAL logging to speed up data loading
Next
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: [Patch] Optimize dropping of relation buffers using dlist