Re: Inlining functions with "expensive" parameters

On November 16, 2017 11:44:52 AM PST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Andres Freund <andres(at)anarazel(dot)de> writes:
>> Well, it's not a question of cost of the function now? Imagine
>> SELECT inlineable(something());
>> if you have 10 references for the parameter inside inlineable(). Then
>> currently something() would be evaluated 10 times. Which'd quite
>> possibly be bad.
>
>Right. I kind of thought we only worried about that if the parameter
>was referenced more than once, but I might be wrong.

You're not.

>> But what I *am* wondering about, is why we're not handling the
>> parameters in a different way. Instead of replacing the all parameter
>> references with the parameter, it shouldn't be too hard to instead
>> replace them with a new PARAM_EXEC like Param.
>
>Yeah, there's no mechanism like that now, but there could be.

Right, but it doesn't sound that hard to introduce. Basically there'd need to be a WithParamValue node, that first evaluates parameters and then executes the child expression. I'm thinking of doing this hierarchically so there's less issues with the setting of the param value being moved away from the child expression using it.

> I wonder
>if we could connect that to the work that was being done for caching
>nonvolatile subexpressions --- it feels like much the same problem.

Yes, that sounds like it could be related. Looks like the expression representation and the execution side of things should be the same.

Andres

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.