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

From Amit Kapila
Subject Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Date
Msg-id CAA4eK1+UXU1ZTyyM=wvZA9wBOMWxoTQezYRM62K7Q_DJhsk6FA@mail.gmail.com
Whole thread Raw
In response to Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Keisuke Kuroda <keisuke.kuroda.3862@gmail.com>)
Responses Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
List pgsql-hackers
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.

> 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...
>

Yeah, it won't be possible before PG14 as it depends on the new
feature added in PG14.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: proposal: schema variables
Next
From: Michael Paquier
Date:
Subject: Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY