On Wed, Sep 11, 2019 at 6:22 PM Robert Haas <robertmh...@gmail.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
