Fwd: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4 - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Fwd: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
Date
Msg-id 65e33e42-080d-2c95-45d9-057ae783ccfd@dunslane.net
Whole thread Raw
Responses Re: Fwd: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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@laurent-hasson.com wrote:
>> > -----Original Message-----
>> > From: Andrew Dunstan <andrew@dunslane.net>
>> > Sent: Sunday, August 22, 2021 17:27
>> > To: Tom Lane <tgl@sss.pgh.pa.us>; ldh@laurent-hasson.com
>> > Cc: Justin Pryzby <pryzby@telsasoft.com>; Ranier Vilela
>> > <ranier.vf@gmail.com>; pgsql-performance@postgresql.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@laurent-hasson.com" <ldh@laurent-hasson.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



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [PATCH] pgbench: add multiconnect option
Next
From: David Christensen
Date:
Subject: Re: [PATCH] pgbench: add multiconnect option