Fwd: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4

Somehow -hackers got left off the cc:

On 8/22/21 6:11 PM, Andrew Dunstan wrote:
> On 8/22/21 5:59 PM, ldh(at)laurent-hasson(dot)com wrote:
>> > -----Original Message-----
>> > From: Andrew Dunstan <andrew(at)dunslane(dot)net>
>> > Sent: Sunday, August 22, 2021 17:27
>> > To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>; ldh(at)laurent-hasson(dot)com
>> > Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>; Ranier Vilela
>> > <ranier(dot)vf(at)gmail(dot)com>; pgsql-performance(at)postgresql(dot)org
>> > Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2
>> > and 13.4
>> > > > On 8/22/21 4:11 PM, Tom Lane wrote:
>> > > "ldh(at)laurent-hasson(dot)com" <ldh(at)laurent-hasson(dot)com> writes:
>> > >> I do have a Linux install of 13.3, and things work beautifully,
>> so this is
>> > definitely a Windows thing here that started in V12.
>> > > It's good to have a box around it, but that's still a pretty
>> large box
>> > > :-(.
>> > >
>> > > I'm hoping that one of our Windows-using developers will see if they
>> > > can reproduce this, and if so, try to bisect where it started.
>> > > Not sure how to make further progress without that.
>> > >
>> > >
>> > > > Can do. Assuming the assertion that it started in Release 12 is
>> correct, I
>> > should be able to find it by bisecting between the branch point for 12
>> > and the tip of that branch. That's a little over 20 probes by my
>> > calculation.
>> > > > cheers
>> > > > andrew
>> > > > --
>> > Andrew Dunstan
>> > EDB: https://www.enterprisedb.com
>>
>>
>> I tried it on 11.13 and 12.3. Is there a place where I could download
>> 12.1 and 12.2 and test that? Is it worth it or you think you have all
>> you need?
>>
>
> I think I have everything I need.
>
>
> Step one will be to verify that the difference exists between the branch
> point and the tip of release 12. Once that's done it will be a matter of
> probing until the commit at fault is identified.
>

OK, here's what we know.

First, this apparently only affects build done with NLS. And in fact
even on release 11 the performance is much better when run on a non-NLS
build. So there's lots of work to do here.

I can't yet pinpoint the place where it got disastrously bad, because I
can't build with VS2017 back past commit a169155453 on the REL_13_STABLE
branch. That commit fixed an issue with VS2015 and newer.

The machine that runs bowerbird has some older VS installations, and
choco has vs2013 packages, so there are opportunities to explore
further. I'll get back to this in a couple of days.

Thanks to my EDB colleagues Sandeep Thakkar and Tushar Ahuja for helping
to identify the cause of the issue.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com