"ldh@laurent-hasson.com" <ldh@laurent-hasson.com> writes:
> OK... I apologize for the long email before. Right after I sent it, I thought of a much simpler use-case to
illustratethe issue which doesn't depend on any special data I have access o and complex pivoting. It's as raw as I can
makeit.
> I create a table with 1M rows and 2 columns. Column "a" is a random string, while column "b" is a random integer as a
string.Then I use a UDF that converts strings to floats and handles an exception if the incoming string is not parsable
asa float. Then I do a simple select of each column. In the "a" case, the UDF throws and catches lots of exceptions. In
the"b" case, the conversion is clean and exceptions are not thrown.
I tried this script on a few different versions and got
these psql-measured timings for the test queries:
HEAD:
Time: 12234.297 ms (00:12.234)
Time: 3029.643 ms (00:03.030)
v14:
Time: 12519.038 ms (00:12.519)
Time: 3211.315 ms (00:03.211)
v13:
Time: 12132.026 ms (00:12.132)
Time: 3114.582 ms (00:03.115)
v12:
Time: 11787.554 ms (00:11.788)
Time: 3520.875 ms (00:03.521)
v11:
Time: 13066.495 ms (00:13.066)
Time: 3503.790 ms (00:03.504)
v10:
Time: 15890.844 ms (00:15.891)
Time: 4999.843 ms (00:05.000)
(Caveats: these are assert-enabled debug builds, so they're all
slower than production builds, but the overhead should be pretty
uniform across branches I think. Also, I wasn't trying hard to
eliminate noise, e.g. I didn't do multiple runs. So I wouldn't
trust these results to be reproducible to better than 10% or so.)
The overhead of an EXCEPTION block is definitely high, and more
so when an exception actually occurs, but these are known facts
and my results are not out of line with my expectations. Yours
are though, so something is drastically slowing the exception-
recovery path in your installation. Do you have any extensions
loaded?
regards, tom lane