čt 23. 7. 2020 v 21:43 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Andres Freund <andres@anarazel.de> writes: > On 2020-07-23 18:50:32 +0100, Dagfinn Ilmari Mannsåker wrote: >> Would it be feasible to set up an exception handler when constant- >> folding cases that might not be reached, and leave the expression >> unfolded only if an error was thrown, or does that have too much >> overhead to be worthwhile?
> That'd require using a subtransaction for expression > simplification. That'd be way too high overhead.
That's my opinion as well. It'd be a subtransaction for *each* operator/function call we need to simplify, which seems completely disastrous.
> Given how often we've had a need to call functions while handling > errors, I do wonder if it'd be worthwhile and feasible to mark functions > as being safe to call without subtransactions, or mark them as not > erroring out (e.g. comparators would usually be safe).
Yeah. I was wondering whether the existing "leakproof" marking would be adequate for this purpose. It's a little stronger than what we need, but the pain-in-the-rear factor for adding YA function property is high enough that I'm inclined to just use it anyway.
We do have to assume that "leakproof" includes "cannot throw any input-dependent error", but it seems to me that that's true.
I am afraid of a performance impact.
lot of people expects constant folding everywhere now and I can imagine query like
SELECT CASE col1 WHEN 1 THEN upper('hello') ELSE upper('bye') END FROM ...
Now, it is optimized well, but with the proposed patch, this query can be slow.
We should introduce planner safe functions for some usual functions, or maybe better explain the behaviour, the costs, and benefits. I don't think this issue is too common.
