I said:
> There is some code in the function inliner to abandon inlining if an
> input expression is "too expensive", but its notion of "too expensive"
> is currently just "contains subselects". I'm going to see if it helps
> to reject inlining when the input grows "too large", for some value of
> "too large".
Okay, after further study, I see that the real problem here is that when
expanding nested concat_ws calls, the expansions of the lower-level
calls would get substituted in more than one place in the outer
functions. Specifically, since $2 occurs twice in the bottom-level
function, you'd end up with an expanded tree of O(2^n) nodes for n
levels of function call.
I added code to inline_function to stop inlining if a parameter
expression to be substituted multiple times has cost greater than
10*cpu_operator_cost (which roughly means that it contains more than
10 operators or functions). This seems to cut off the problem nicely,
at least for this example. The factor of 10 is a bit of a magic number
but it seems reasonable.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
