Re: [HACKERS] [ADMIN] concat_ws

2003-08-04 Thread Tom Lane
=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <[EMAIL PROTECTED]> writes: > On Sun, 3 Aug 2003, Tom Lane wrote: >> 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

Re: [HACKERS] [ADMIN] concat_ws

2003-08-03 Thread Dennis Björklund
On Sun, 3 Aug 2003, Tom Lane wrote: > 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). When is this inlining taki

Re: [HACKERS] [ADMIN] concat_ws

2003-08-03 Thread Joe Conway
Tom Lane wrote: 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

Re: [HACKERS] [ADMIN] concat_ws

2003-08-03 Thread Tom Lane
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 >

Re: [HACKERS] [ADMIN] concat_ws

2003-08-03 Thread Tom Lane
Joe Conway <[EMAIL PROTECTED]> writes: > But I wonder why it isn't at all a problem when the function is also > defined STRICT? Because the inliner doesn't think it can safely inline in that case; the substituted expression isn't strict and so inlining would potentially change the semantics.

Re: [HACKERS] [ADMIN] concat_ws

2003-08-03 Thread Joe Conway
Tom Lane wrote: Yeah. The problem is that the SQL function inliner generates an enormous expression tree from this function definition. 7.3 had no inliner so no problem. But I wonder why it isn't at all a problem when the function is also defined STRICT? I also looked back at the greatest() exa

Re: [HACKERS] [ADMIN] concat_ws

2003-08-03 Thread Tom Lane
Joe Conway <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> It seems to be running out of memory. > Also worth noting, without STRICT, even a plain EXPLAIN *without* > ANALYZE causes the problem to show itself. Yeah. The problem is that the SQL function inliner generates an enormous expression