Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Date
Msg-id CANP8+j+-f29yBS=B-Z7nQik-5DMrnPBxb_A4eVj3XQyRN+gbnw@mail.gmail.com
Whole thread Raw
In response to Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
List pgsql-hackers
On Fri, 9 Oct 2020 at 04:10, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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.

The test appears to only cover the case of many subtransactions, all
of which commit, and then top-level commit occurs.

We should be testing cases where the top-level commit occurs, yet some
proportion of the subtransactions abort. "Normal" would be 10-50%
aborts.

I presume we support this case already, but wish to ensure the
performance tweak is not just for the one special case.

Thanks

-- 
Simon Riggs                http://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [PATCH] ecpg: fix progname memory leak
Next
From: Amit Kapila
Date:
Subject: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables