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

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Дата
Msg-id CAFiTN-sywC0z_FNA-z-KeMzzj7ev82V4-0bjmQKsO+aqQjZvyQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Fri, Oct 9, 2020 at 2:34 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Oct 9, 2020 at 2:19 PM Simon Riggs <simon@2ndquadrant.com> wrote:
> >
> > 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.
> >
>
> 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


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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [HACKERS] Runtime Partition Pruning
Следующее
От: John Naylor
Дата:
Сообщение: Re: Add primary keys to system catalogs