Thread: Re: [ADMIN] concat_ws

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

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 this example.  The factor of 10 is a bit of a magic number
> but it seems reasonable.
>

That did it (on fresh copy of cvs):

regression=# explain analyze select

concat_ws('~','01','02','03','04','05','06','07','08','09','10','11','12','13','14','15','16','17','18','19','20','21','22','23','24','25','26','27','28','29','30','31');
                                     QUERY PLAN
----------------------------------------------------------------------------------
  Result  (cost=0.00..0.11 rows=1 width=0) (actual time=2.37..2.37
rows=1 loops=1)
  Total runtime: 2.66 msec
(2 rows)

Thanks Tom!

Joe

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 taking place and what is the logic? I just want to
make sure that there is no code in pg that will unfold forever, say for
example for a recursive fac() function. From the above it sounds like that
might be a problem.

--
/Dennis

=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <db@zigo.dhs.org> 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 more than
>> 10 operators or functions).

> When is this inlining taking place and what is the logic? I just want to
> make sure that there is no code in pg that will unfold forever, say for
> example for a recursive fac() function. From the above it sounds like that
> might be a problem.

That's already dealt with.  See inline_function() in
src/backend/optimizer/util/clauses.c.

            regards, tom lane