At Thu, 12 Sep 2019 09:44:49 +0530, Dilip Kumar <dilipbal...@gmail.com> wrote
in <CAFiTN-u8sp=1x+zk0hbpcyhzvys6k1dct+r3p+fucku3is7...@mail.gmail.com>
> On Wed, Sep 11, 2019 at 6:22 PM Robert Haas <robertmh...@gmail.com> wrote:
> > 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)
I see the similar result. The patch let it run faster by about
25%. The gain is reduced to 3-6% by a crude check by adding { (in
TopTxCxt) lcons(0, p1); lcons(0, p2); } to the place where
AtSubStart_Notify was called and respective list_delete_first's
just after the call to AtSubCommit_Notfiy. At least around 20% of
the gain seems to be the result of removing palloc/pfree's.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
