Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
On Sun, Aug 22, 2021 at 10:50:47AM -0300, Ranier Vilela wrote: > > Tried to check this with Very Sleepy at Windows 10 (bare metal). > > Not sure it can help if someone can guide how to test this better? > explain (analyze,buffers,COSTS,TIMING) select MAX(toFloat(a, null)) as "a" > from sampletest; Your 100sec result *seems* to reproduce the problem, but it'd be more clear if you showed the results of both queries (toFloat(a) vs toFloat(b)). Laurent's queries took 800sec vs 2sec. > postgres.png (print screen from Very Sleepy) > postgres.csv This looks useful, thanks. It seems like maybe win64 builds are very slow running this: exec_stmt_block() / BeginInternalSubTransaction() / AbortSubTransaction() / reschedule_timeouts() / schedule_alarm() / setitimer() / pg_timer_thread() / WaitForSingleObjectEx () We should confirm whether there's a dramatic regression caused by postgres source code (and not by compilation environment or windows version changes). Test if there's a dramatic difference between v11 and v12, or v12 and v13. To be clear, the ~4x difference in v11 between Laurent's "exceptional" and "nonexceptional" cases is expected. But the 400x difference in v13 is not. If it's due to a change in postgres source code, we should find what commit caused the regression. First, check if v12 is affected. Right now, we know that v11.2 is ok and v13.4 is not ok. Then (unless someone has a hunch where to look), you could use git bisect to find the culprit commit. Git log shows 85 commits affecting those files across the 2 branches - once we determine whether v12 is affected, that alone eliminates a significant fraction of the commits to be checked. git log --oneline --cherry-pick origin/REL_11_STABLE...origin/REL_13_STABLE src/backend/access/transam/xact.c src/backend/port/win32/timer.c src/backend/utils/misc/timeout.c src/pl/plpgsql/src/pl_exec.c -- Justin
Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
Justin Pryzby writes: > This looks useful, thanks. It seems like maybe win64 builds are very slow > running this: > exec_stmt_block() / > BeginInternalSubTransaction() / > AbortSubTransaction() / > reschedule_timeouts() / > schedule_alarm() / > setitimer() / > pg_timer_thread() / > WaitForSingleObjectEx () Hmm ... we should not be there unless there are active timeout events, which there aren't by default. I wonder whether either Ranier or Laurent have statement_timeout or some similar option enabled. I tried setting statement_timeout = '1 min' just to see if that would affect the results. It does, but only incrementally on my Linux box (on v13, the exception-causing query slows from ~13sec to ~14sec). It's possible that our Windows version of setitimer() is far slower, but that doesn't make a lot of sense really --- the client side of that just briefly takes a critical section. It shouldn't be blocking. Also, the Windows version (src/backend/port/win32/timer.c) hasn't changed at all since before v11. So even if it's slow, that doesn't tell us what changed. There is a patch in v14 (09cf1d522) that drastically reduces the rate at which we make setitimer() calls, which would likely be enough to fix any performance problem that may exist here. But it's still unclear what's different between v11 and v13. regards, tom lane
RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
> -Original Message- > From: Justin Pryzby > Sent: Sunday, August 22, 2021 11:48 > To: Ranier Vilela > Cc: [email protected]; Tom Lane ; pgsql- > [email protected] > Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 > and 13.4 > > On Sun, Aug 22, 2021 at 10:50:47AM -0300, Ranier Vilela wrote: > > > Tried to check this with Very Sleepy at Windows 10 (bare metal). > > > Not sure it can help if someone can guide how to test this better? > > > explain (analyze,buffers,COSTS,TIMING) select MAX(toFloat(a, null)) as > > "a" from sampletest; > > Your 100sec result *seems* to reproduce the problem, but it'd be more > clear if you showed the results of both queries (toFloat(a) vs toFloat(b)). > Laurent's queries took 800sec vs 2sec. > > > postgres.png (print screen from Very Sleepy) postgres.csv > > This looks useful, thanks. It seems like maybe win64 builds are very slow > running this: > > exec_stmt_block() / > BeginInternalSubTransaction() / > AbortSubTransaction() / > reschedule_timeouts() / > schedule_alarm() / > setitimer() / > pg_timer_thread() / > WaitForSingleObjectEx () > > We should confirm whether there's a dramatic regression caused by > postgres source code (and not by compilation environment or windows > version changes). > Test if there's a dramatic difference between v11 and v12, or v12 and > v13. > To be clear, the ~4x difference in v11 between Laurent's "exceptional" > and "nonexceptional" cases is expected. But the 400x difference in v13 > is not. > > If it's due to a change in postgres source code, we should find what > commit caused the regression. > > First, check if v12 is affected. Right now, we know that v11.2 is ok and > v13.4 is not ok. Then (unless someone has a hunch where to look), you > could use git bisect to find the culprit commit. > > Git log shows 85 commits affecting those files across the 2 branches - > once we determine whether v12 is affected, that alone eliminates a > significant fraction of the commits to be checked. > > git log --oneline --cherry-pick > origin/REL_11_STABLE...origin/REL_13_STABLE > src/backend/access/transam/xact.c src/backend/port/win32/timer.c > src/backend/utils/misc/timeout.c src/pl/plpgsql/src/pl_exec.c > > -- > Justin So, I have other installs of Postgres I can also test on my laptop. No VM, straight install of Windows 10. PostgreSQL 12.3, compiled by Visual C++ build 1914, 64-bit install No-exceptions scenario --- Aggregate (cost=14778.40..14778.41 rows=1 width=4) (actual time=1462.836..1462.837 rows=1 loops=1) Buffers: shared hit=6379 -> Seq Scan on sampletest (cost=0.00..11975.60 rows=560560 width=32) (actual time=0.020..86.506 rows=100 loops=1) Buffers: shared hit=6370 Planning Time: 0.713 ms Execution Time: 1463.359 ms Exceptions scenario --- I canceled the query after 18mn... PostgreSQL 11.1, compiled by Visual C++ build 1914, 64-bit No-exceptions scenario --- Aggregate (cost=14778.40..14778.41 rows=1 width=4) (actual time=1784.915..1784.915 rows=1 loops=1) Buffers: shared hit=6377 -> Seq Scan on sampletest (cost=0.00..11975.60 rows=560560 width=32) (actual time=0.026..107.194 rows=100 loops=1) Buffers: shared hit=6370 Planning Time: 0.374 ms Execution Time: 1785.203 ms Exceptions scenario --- Aggregate (cost=14778.40..14778.41 rows=1 width=4) (actual time=33891.778..33891.778 rows=1 loops=1) Buffers: shared hit=6372 -> Seq Scan on sampletest (cost=0.00..11975.60 rows=560560 width=32) (actual time=0.015..171.325 rows=100 loops=1) Buffers: shared hit=6370 Planning Time: 0.090 ms Execution Time: 33891.806 ms
RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
> -Original Message- > From: Tom Lane > Sent: Sunday, August 22, 2021 13:51 > To: Justin Pryzby > Cc: Ranier Vilela ; [email protected]; > [email protected] > Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 > and 13.4 > > Justin Pryzby writes: > > This looks useful, thanks. It seems like maybe win64 builds are very > > slow running this: > > > exec_stmt_block() / > > BeginInternalSubTransaction() / > > AbortSubTransaction() / > > reschedule_timeouts() / > > schedule_alarm() / > > setitimer() / > > pg_timer_thread() / > > WaitForSingleObjectEx () > > Hmm ... we should not be there unless there are active timeout events, > which there aren't by default. I wonder whether either Ranier or > Laurent have statement_timeout or some similar option enabled. > > I tried setting statement_timeout = '1 min' just to see if that would affect > the results. It does, but only incrementally on my Linux box (on v13, the > exception-causing query slows from ~13sec to ~14sec). It's possible that > our Windows version of > setitimer() is far slower, but that doesn't make a lot of sense really --- the > client side of that just briefly takes a critical section. It shouldn't be > blocking. > > Also, the Windows version (src/backend/port/win32/timer.c) hasn't > changed at all since before v11. So even if it's slow, that doesn't tell us > what changed. > > There is a patch in v14 (09cf1d522) that drastically reduces the rate at > which we make setitimer() calls, which would likely be enough to fix any > performance problem that may exist here. > But it's still unclear what's different between v11 and v13. > >regards, tom lane Hello Tom, On both my clean 13.4 install and current 11.2 install, I have #statement_timeout = 0 # in milliseconds, 0 is disabled Note that the 13.4 clean install I gave last measurements for has all stock settings. Thank you, Laurent.
RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
> -Original Message- > From: [email protected] > Sent: Sunday, August 22, 2021 14:37 > To: Tom Lane ; Justin Pryzby > > Cc: Ranier Vilela ; pgsql- > [email protected] > Subject: RE: Big Performance drop of Exceptions in UDFs between V11.2 > and 13.4 > > > > > -Original Message- > > From: Tom Lane > > Sent: Sunday, August 22, 2021 13:51 > > To: Justin Pryzby > > Cc: Ranier Vilela ; [email protected]; > > [email protected] > > Subject: Re: Big Performance drop of Exceptions in UDFs between > V11.2 > > and 13.4 > > > > Justin Pryzby writes: > > > This looks useful, thanks. It seems like maybe win64 builds are > very > > > slow running this: > > > > > exec_stmt_block() / > > > BeginInternalSubTransaction() / > > > AbortSubTransaction() / > > > reschedule_timeouts() / > > > schedule_alarm() / > > > setitimer() / > > > pg_timer_thread() / > > > WaitForSingleObjectEx () > > > > Hmm ... we should not be there unless there are active timeout > events, > > which there aren't by default. I wonder whether either Ranier or > > Laurent have statement_timeout or some similar option enabled. > > > > I tried setting statement_timeout = '1 min' just to see if that would > affect > > the results. It does, but only incrementally on my Linux box (on v13, > the > > exception-causing query slows from ~13sec to ~14sec). It's possible > that > > our Windows version of > > setitimer() is far slower, but that doesn't make a lot of sense really --- > the > > client side of that just briefly takes a critical section. It shouldn't be > > blocking. > > > > Also, the Windows version (src/backend/port/win32/timer.c) hasn't > > changed at all since before v11. So even if it's slow, that doesn't tell > us > > what changed. > > > > There is a patch in v14 (09cf1d522) that drastically reduces the rate > at > > which we make setitimer() calls, which would likely be enough to fix > any > > performance problem that may exist here. > > But it's still unclear what's different between v11 and v13. > > > > regards, tom lane > > > Hello Tom, > > On both my clean 13.4 install and current 11.2 install, I have > #statement_timeout = 0# in milliseconds, 0 is > disabled > > Note that the 13.4 clean install I gave last measurements for has all stock > settings. > > Thank you, > Laurent. > > One more fresh install, of 11.13 this time and the issue is not there... 😊 Aggregate (cost=14778.40..14778.41 rows=1 width=4) (actual time=1963.573..1963.574 rows=1 loops=1) Buffers: shared hit=6377 -> Seq Scan on sampletest (cost=0.00..11975.60 rows=560560 width=32) (actual time=0.027..110.896 rows=100 loops=1) Buffers: shared hit=6370 Planning Time: 0.427 ms Execution Time: 1963.981 ms Aggregate (cost=21370.00..21370.01 rows=1 width=4) (actual time=31685.853..31685.853 rows=1 loops=1) Buffers: shared hit=6370 -> Seq Scan on sampletest (cost=0.00..16370.00 rows=100 width=15) (actual time=0.029..180.664 rows=100 loops=1) Buffers: shared hit=6370 Planning Time: 0.092 ms Execution Time: 31685.904 ms I am still experiencing a larger slowdown in the "with-exceptions" scenario being 16x slower compared to other measurements you have all produced.. But at least, it's manageable compared to the multi 100x times. So, now, in summary: - I have tried V13.4, V12.3, 11.13, 11.2, 11.1 on several Windows VMs and my personal laptop (no VM). - All V11.x seem to behave uniformly. - Starting with 12.3, I am experiencing the major slowdown in the "with exceptions" scenario. So, I was thinking about stuff and a lot of your intuitions seem to drive towards an issue with the compiler used to compile the Winx64 version... But is it possible that the JIT is getting in there and making things weird? Given that it's a major change in V12 and this is when I am starting to see the issue popup, I figured it might be another avenue to look into? Thank you, Laurent Hasson.
Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
"[email protected]" writes: > So, now, in summary: > - I have tried V13.4, V12.3, 11.13, 11.2, 11.1 on several Windows VMs and my > personal laptop (no VM). > - All V11.x seem to behave uniformly. > - Starting with 12.3, I am experiencing the major slowdown in the "with > exceptions" scenario. Interesting. There's no meaningful difference between v11 and v12 as far as timeout handling goes, so I'm starting to think that that's a red herring. (Although, after having done some web-searching, I do wonder why timer.c is using a manual-reset event. It looks like auto-reset would work just as well with less code, and I found some suggestions that it might perform better.) > So, I was thinking about stuff and a lot of your intuitions seem to drive > towards an issue with the compiler used to compile the Winx64 version... But > is it possible that the JIT is getting in there and making things weird? > Given that it's a major change in V12 and this is when I am starting to see > the issue popup, I figured it might be another avenue to look into? Hm, is JIT even enabled in your build? If so, does setting jit = 0 change anything? regards, tom lane
RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
> -Original Message- > From: Tom Lane > Sent: Sunday, August 22, 2021 15:24 > To: [email protected] > Cc: Justin Pryzby ; Ranier Vilela > ; [email protected] > Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 > and 13.4 > > "[email protected]" writes: > > So, now, in summary: > > > - I have tried V13.4, V12.3, 11.13, 11.2, 11.1 on several Windows VMs > and my personal laptop (no VM). > > - All V11.x seem to behave uniformly. > > - Starting with 12.3, I am experiencing the major slowdown in the > "with exceptions" scenario. > > Interesting. There's no meaningful difference between v11 and v12 as > far as timeout handling goes, so I'm starting to think that that's a red > herring. > > (Although, after having done some web-searching, I do wonder why > timer.c is using a manual-reset event. It looks like auto-reset would > work just as well with less code, and I found some suggestions that it > might perform better.) > > > So, I was thinking about stuff and a lot of your intuitions seem to drive > towards an issue with the compiler used to compile the Winx64 > version... But is it possible that the JIT is getting in there and making > things weird? Given that it's a major change in V12 and this is when I am > starting to see the issue popup, I figured it might be another avenue to > look into? > > Hm, is JIT even enabled in your build? If so, does setting jit = 0 change > anything? > >regards, tom lane Hello Tom, I just ran the test with jit=off in the config and restated the server. No change on 13.4. I'd think that the query cost as per the planner would be too small to kick in the JIT but thought to check anyways. Doesn't seem to be the cause. Thanks., Laurent.
RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
> -Original Message- > From: [email protected] > Sent: Sunday, August 22, 2021 15:29 > To: Tom Lane > Cc: Justin Pryzby ; Ranier Vilela > ; [email protected] > Subject: RE: Big Performance drop of Exceptions in UDFs between V11.2 > and 13.4 > > > > > -Original Message- > > From: Tom Lane > > Sent: Sunday, August 22, 2021 15:24 > > To: [email protected] > > Cc: Justin Pryzby ; Ranier Vilela > > ; [email protected] > > Subject: Re: Big Performance drop of Exceptions in UDFs between > V11.2 > > and 13.4 > > > > "[email protected]" writes: > > > So, now, in summary: > > > > > - I have tried V13.4, V12.3, 11.13, 11.2, 11.1 on several Windows > VMs > > and my personal laptop (no VM). > > > - All V11.x seem to behave uniformly. > > > - Starting with 12.3, I am experiencing the major slowdown in the > > "with exceptions" scenario. > > > > Interesting. There's no meaningful difference between v11 and v12 > as > > far as timeout handling goes, so I'm starting to think that that's a red > > herring. > > > > (Although, after having done some web-searching, I do wonder why > > timer.c is using a manual-reset event. It looks like auto-reset would > > work just as well with less code, and I found some suggestions that it > > might perform better.) > > > > > So, I was thinking about stuff and a lot of your intuitions seem to > drive > > towards an issue with the compiler used to compile the Winx64 > > version... But is it possible that the JIT is getting in there and making > > things weird? Given that it's a major change in V12 and this is when I > am > > starting to see the issue popup, I figured it might be another avenue > to > > look into? > > > > Hm, is JIT even enabled in your build? If so, does setting jit = 0 > change > > anything? > > > > regards, tom lane > > Hello Tom, > > I just ran the test with jit=off in the config and restated the server. No > change on 13.4. I'd think that the query cost as per the planner would be > too small to kick in the JIT but thought to check anyways. Doesn't seem > to be the cause. > > Thanks., > Laurent. > > > > Also Tom, 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. No exceptions - Aggregate (cost=21370.00..21370.01 rows=1 width=4) (actual time=1796.311..1796.313 rows=1 loops=1) Buffers: shared hit=6370 -> Seq Scan on sampletest (cost=0.00..16370.00 rows=100 width=8) (actual time=0.006..113.720 rows=100 loops=1) Buffers: shared hit=6370 Planning: Buffers: shared hit=5 Planning Time: 0.121 ms Execution Time: 1796.346 ms With Exceptions -- Aggregate (cost=14778.40..14778.41 rows=1 width=4) (actual time=6355.051..6355.052 rows=1 loops=1) Buffers: shared hit=6373 -> Seq Scan on sampletest (cost=0.00..11975.60 rows=560560 width=32) (actual time=0.011..163.499 rows=100 loops=1) Buffers: shared hit=6370 Planning Time: 0.064 ms Execution Time: 6355.077 ms
Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
"[email protected]" 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. regards, tom lane
RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
> -Original Message- > From: Tom Lane > Sent: Sunday, August 22, 2021 16:11 > To: [email protected] > Cc: Justin Pryzby ; Ranier Vilela > ; [email protected] > Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 > and 13.4 > > "[email protected]" 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. > >regards, tom lane Hello Tom, If there is any way I can help further... I am definitely not able to do a dev environment and local build, but if we have a windows developer reproducing the issue between 11 and 12, then that should help. If someone makes a debug build available to me, I can provide additional help based on that. That being said, do you have any suggestion how I could circumvent the issue altogether? Is there a way I could convert a String to some type (integer, float, date...) without exceptions and in case of failure, return a default value? Maybe there is a way to do this and I can avoid exception handling altogether? Or use something else than plpgsql? I am always under the impression that plpgsql is the best performing option? I have seen regex-based options out there, but none being fully satisfying for floating points in particular. Thank you, Laurent.
Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
On 8/22/21 4:11 PM, Tom Lane wrote: > "[email protected]" 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
RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
> -Original Message- > From: Andrew Dunstan > Sent: Sunday, August 22, 2021 17:27 > To: Tom Lane ; [email protected] > Cc: Justin Pryzby ; Ranier Vilela > ; [email protected] > 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: > > "[email protected]" 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? Thanks, Laurent.
Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
On 8/22/21 5:59 PM, [email protected] wrote: > >> -Original Message- >> From: Andrew Dunstan >> Sent: Sunday, August 22, 2021 17:27 >> To: Tom Lane ; [email protected] >> Cc: Justin Pryzby ; Ranier Vilela >> ; [email protected] >> 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: >> > "[email protected]" 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. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
Em dom., 22 de ago. de 2021 Ã s 14:50, Tom Lane escreveu: > Justin Pryzby writes: > > This looks useful, thanks. It seems like maybe win64 builds are very > slow > > running this: > > > exec_stmt_block() / > > BeginInternalSubTransaction() / > > AbortSubTransaction() / > > reschedule_timeouts() / > > schedule_alarm() / > > setitimer() / > > pg_timer_thread() / > > WaitForSingleObjectEx () > > Hmm ... we should not be there unless there are active timeout events, > which there aren't by default. I wonder whether either Ranier or > Laurent have statement_timeout or some similar option enabled. > Tom, none settings, all default from Postgres install. regards, Ranier Vilela
Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
Em dom., 22 de ago. de 2021 Ã s 18:12, [email protected] < [email protected]> escreveu: > > >> -Original Message- >> From: Tom Lane >> Sent: Sunday, August 22, 2021 16:11 >> To: [email protected] >> Cc: Justin Pryzby ; Ranier Vilela >> ; [email protected] >> Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 >> and 13.4 >> >> "[email protected]" 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. >> >>regards, tom lane > > Hello Tom, > > If there is any way I can help further... I am definitely not able to do a > dev environment and local build, but if we have a windows developer > reproducing the issue between 11 and 12, then that should help. If someone > makes a debug build available to me, I can provide additional help based on > that. > Please, download from this link (Google Drive): https://drive.google.com/file/d/13kPbNmk54lR6t-lwcwi-63UdM55sA27t/view?usp=sharing Postgres Debug (64 bits) HEAD. regards, Ranier Vilela
Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
On Sun, Aug 22, 2021 at 08:44:34PM -0300, Ranier Vilela wrote: > > If there is any way I can help further... I am definitely not able to do a > > dev environment and local build, but if we have a windows developer > > reproducing the issue between 11 and 12, then that should help. If someone > > makes a debug build available to me, I can provide additional help based on > > that. > > Please, download from this link (Google Drive): > > https://drive.google.com/file/d/13kPbNmk54lR6t-lwcwi-63UdM55sA27t/view?usp=sharing Laurent gave a recipe to reproduce the problem, and you seemed to be able to reproduce it, so I think Laurent's part is done. The burden now lies with postgres developers to isolate the issue, and Andrew said he would bisect to look for the culprit commit. -- Justin
RE: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
> -Original Message- > From: Justin Pryzby > Sent: Sunday, August 22, 2021 20:43 > To: Ranier Vilela > Cc: [email protected]; Tom Lane ; pgsql- > [email protected] > Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 > and 13.4 > > On Sun, Aug 22, 2021 at 08:44:34PM -0300, Ranier Vilela wrote: > > > If there is any way I can help further... I am definitely not able > > > to do a dev environment and local build, but if we have a windows > > > developer reproducing the issue between 11 and 12, then that > should > > > help. If someone makes a debug build available to me, I can provide > > > additional help based on that. > > > > Please, download from this link (Google Drive): > > > > https://drive.google.com/file/d/13kPbNmk54lR6t-lwcwi- > 63UdM55sA27t/view > > ?usp=sharing > > Laurent gave a recipe to reproduce the problem, and you seemed to be > able to reproduce it, so I think Laurent's part is done. The burden now > lies with postgres developers to isolate the issue, and Andrew said he > would bisect to look for the culprit commit. > > -- > Justin Hello Ranier, I am not sure what to do with that build. I am a Java/JavaScript guy these days. I haven't coded C/C++ in over 15 years now and I don't have a debugging environment 😊 If I can run the scenario I created and get a log file, that I can do if that helps. Justin, I think I agree with you although I am concerned that none of you were able to truly reproduce the results I have now reproduced on plain base-line installs on 2 VMs (Windows Server 2012) and a laptop (Windows 10 pro), across multiple versions of the installer (11, 12 and 13). In any case, i'll do my best to help. If you think you have a fix and it's in one dll or exe and I can just manually patch a 13.4 install and test again, I'll do that with pleasure. Thank you, Laurent.
