Re: let's kill AtSubStart_Notify

From: Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: let's kill AtSubStart_Notify
Date: 2019-09-27 09:41:02
Message-ID: CAOgcT0NvoGatroqrcgM4M7bLR6=ntSSbBQQyJUbfE6gzXs8D9g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Robert,

Generally, a subsystem can avoid needing a callback at subtransaction
> start (or transaction start) by detecting new levels of
> subtransactions at time of use.

Yes I agree with this argument.

> A typical practice is to maintain a
> stack which has entries only for those transaction nesting levels
> where the functionality was used. The attached patch implements this
> method for async.c.

I have reviewed your patch, and it seems correctly implementing the
actions per subtransactions using stack. Atleast I could not find
any flaw with your implementation here.

> I was a little surprised to find that it makes a
> pretty noticeable performance difference when starting and ending
> trivial subtransactions. I used this test case:
>
> \timing
> do $$begin for i in 1 .. 10000000 loop begin null; exception when
> others then null; end; end loop; end;$$;
>

I ran your testcase and on my VM I get numbers like 3593.801 ms
without patch and 3593.801 with the patch, average of 5 runs each.
The runs were quite consistent.

Further make check also passing well.

Regards,
Jeevan Ladhe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexandra Wang 2019-09-27 09:42:35 Re: Zedstore - compressed in-core columnar storage
Previous Message Amit Kapila 2019-09-27 09:40:46 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions