Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Keisuke Kuroda <keisuke(dot)kuroda(dot)3862(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(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-01 03:49:53
Message-ID: CAA4eK1+UXU1ZTyyM=wvZA9wBOMWxoTQezYRM62K7Q_DJhsk6FA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 1, 2020 at 8:22 AM Keisuke Kuroda
<keisuke(dot)kuroda(dot)3862(at)gmail(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-10-01 03:50:39 Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Previous Message Michael Paquier 2020-10-01 03:38:24 Re: proposal: schema variables