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+y5Re=vhiOey8TASo1oaaXQMbV+bGC5DMzDOcHO6HN6g@mail.gmail.com
Whole thread Raw
In response to Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Simon Riggs <simon@2ndquadrant.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 8, 2020 at 2:34 PM Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On Thu, 8 Oct 2020 at 09:47, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> > > This script will wait 10 seconds after INSERT exits
> > > before executing TRUNCATE, please wait for it to run.
>
> Has this been tested with anything other than the one test case?
>
> It would be good to know how the patch handles a transaction that
> contains many aborted subtransactions that contain invals.
>

Are you thinking from the angle of performance or functionality? I
don't see how this patch can impact either of those. Basically, it
will not execute any extra invalidations then it is executing without
the patch for aborted subtransactions. Can you please explain in a bit
more detail about your fear?

Having said that, I think it would be a good idea to test the scenario
you mentioned to ensure that we have not broken anything unknowingly.


-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: POC: postgres_fdw insert batching
Next
From: Amit Kapila
Date:
Subject: Re: Fix typos in reorderbuffer.c