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 CAA4eK1Ki56ZoaUMX4zRqxRnUVTn8CR7EJ_x3_8vJUnO6FuaStQ@mail.gmail.com
Whole thread Raw
In response to Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On Mon, Oct 12, 2020 at 3:23 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Fri, Oct 9, 2020 at 2:34 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> >
> > Okay, I think this makes sense. I think we should see the performance
> > benefit for this case as well but maybe to a bit lesser degree because
> > we will exclude some of the subtransactions from processing.
>
> I have tried with a combination of abort/commit subtransaction and I
> could see a similar benefit with the patch.
>
> I tested below transaction
> BEGIN;
> truncate table nsp_001.tbl_001;
> savepoint s1;
> truncate table nsp_001.tbl_001;
> savepoint s2;
> truncate table part_0001;
> savepoint s3;
> truncate table part_0002;
> savepoint s5;
> truncate table part_0003;
> rollback to s3;
> commit;
> EOF
>

Thanks for the tests. The latest patch looks mostly good to me. I have
made minor changes to the patch (a) changed the order where the new
message is placed at one place to make it consistent with other
places, (b) as discussed offlist, removed the extra increment to a
local variable in ReorderBufferRestoreChange, (c) ran pgindent.

See the attached and let me know what do you think?

-- 
With Regards,
Amit Kapila.

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Transactions involving multiple postgres foreign servers, take 2
Next
From: Dilip Kumar
Date:
Subject: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables