Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Keisuke Kuroda <keisuke.kuroda.3862@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-01T04:18:39Z
Lists: pgsql-hackers
On Thu, Oct 1, 2020 at 9:19 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Oct 1, 2020 at 8:22 AM Keisuke Kuroda > <keisuke.kuroda.3862@gmail.com> wrote: > > > > 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 > > > > Does this result indicate that it is still CPU bound but it does the > actual decoding and completes in 1s instead of spending 230s mainly to > execute unnecessary invalidations? > > > 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); > > > > From the patch perspective, I think it is better if we can add one > test case as well where we process some invalidations and then the > rollback happens and we need to process all the invalidations > together. Basically, this is to cover the new code, if such a test > already exists then it is fine. I think we already have such a test case. 019_stream_subxact_ddl_abort.pl is covering this scenario. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
Execute invalidation messages for each XLOG_XACT_INVALIDATIONS message
- d7eb52d7181d 14.0 landed
-
WAL Log invalidations at command end with wal_level=logical.
- c55040ccd017 14.0 cited