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

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Дата
Msg-id CAA4eK1+y5Re=vhiOey8TASo1oaaXQMbV+bGC5DMzDOcHO6HN6g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Dilip Kumar <dilipbalaut@gmail.com>)
Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Simon Riggs <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: "tsunakawa.takay@fujitsu.com"
Дата:
Сообщение: RE: POC: postgres_fdw insert batching
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Fix typos in reorderbuffer.c