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

On Wed, Oct 14, 2020 at 4:12 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> 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?

The changes look good to me.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com