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
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 |