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

Em dom., 22 de ago. de 2021 às 12:48, Justin Pryzby <pryzby(at)telsasoft(dot)com>
escreveu:

> 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.
>
Not, in this test is only with toFloat(a).

> > 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 ()
>
Now, test with toFloat(b):

postgres=# explain (analyze,buffers,COSTS,TIMING) select MAX(toFloat(b,
null)) as "b" from sampletest;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=21370.00..21370.01 rows=1 width=4) (actual
time=16878.424..16878.426 rows=1 loops=1)
Buffers: shared hit=64 read=6306
-> Seq Scan on sampletest (cost=0.00..16370.00 rows=1000000 width=8)
(actual time=0.105..937.201 rows=1000000 loops=1)
Buffers: shared hit=64 read=6306
Planning Time: 0.273 ms
Execution Time: 16878.490 ms
(6 rows)

It seems to me that in this way, exec_stmt_block() is not called.
Not sure if this really is correct. I need to choose postgres.exe to attach
Very Sleepy.

Attached:
to_Float_b.png
to_Float_b.csv

regards,
Ranier Vilela