Re: let's kill AtSubStart_Notify

On Wed, Sep 11, 2019 at 6:22 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> There are only four subsystems which require a callback at the
> beginning of each subtransaction: the relevant functions are
> AtSubStart_Memory, AtSubStart_ResourceOwner, AtSubStart_Notify, and
> AfterTriggerBeginSubXact. The AtSubStart_Memory and
> AtSubStart_ResourceOwner callbacks seem relatively unobjectionable,
> because almost every subtransaction is going to allocate memory and
> acquire some resource managed by a resource owner, but the others
> represent initialization that has to be done whether or not the
> corresponding feature is used.
>
> Generally, a subsystem can avoid needing a callback at subtransaction
> start (or transaction start) by detecting new levels of
> subtransactions at time of use. 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 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 the test four times with and without the patch and took the
> median of the last three. This was an attempt to exclude effects due
> to starting up the database cluster. With the patch, the result was
> 3127.377 ms; without the patch, it was 3527.285 ms. That's a big
> enough difference that I'm wondering whether I did something wrong
> while testing this, so feel free to check my work and tell me whether
> I'm all wet. Still, I don't find it wholly unbelievable, because I've
> observed in the past that these code paths are lean enough that a few
> palloc() calls can make a noticeable difference, and the effect of
> this patch is to remove a few palloc() calls.

I did not read the patch but run the same case what you have given and
I can see the similar improvement with the patch.
With the patch 8832.988, without the patch 10252.701ms (median of three reading)

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