| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Keisuke Kuroda <keisuke(dot)kuroda(dot)3862(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables |
| Date: | 2020-10-09 03:10:22 |
| Message-ID: | CAA4eK1+y5Re=vhiOey8TASo1oaaXQMbV+bGC5DMzDOcHO6HN6g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 8, 2020 at 2:34 PM Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On Thu, 8 Oct 2020 at 09:47, Dilip Kumar <dilipbalaut(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2020-10-09 03:13:19 | Re: Fix typos in reorderbuffer.c |
| Previous Message | tsunakawa.takay@fujitsu.com | 2020-10-09 03:01:53 | RE: POC: postgres_fdw insert batching |