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

On Mon, Oct 12, 2020 at 3:23 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Fri, Oct 9, 2020 at 2:34 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.