Re: Inlining functions with "expensive" parameters

On Thu, Nov 16, 2017 at 12:37 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2017-11-16 15:27:59 -0500, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > On November 16, 2017 11:44:52 AM PST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> wrote:
> > >> 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.
> >
> > Yeah. If you also gave it the ability to optionally enforce strictness
> > (ie, skip child expr and return NULL if any param is NULL) then we could
> > do away with all of the parameter-based restrictions on inlining, since
> > the semantics of parameter eval wouldn't change by inlining.
>
> Yep. And we quite easily can have a fastpath execution step that skips
> these checks if no needed.
>
> I suspect there might still be some cases where it's worth either using
> the current parameter replacement, or rely on eval_const_expressions
> based infrastructure to directly "inline" reference parameters if
> safe. The latter seems a bit nicer / more extensible.
>
>
> > I might be showing my grad school background here, but I'd be inclined to
> > call it a LambdaExpr. A name based on "with" would be fine in a green
> > field, but IMO we've got too much baggage from nodes related to SQL WITH.
>
> That'd work as well for me.
>

Is there a github branch or an active patch set where this work is going on
that I could watch and learn from?
Thanks!
P

> Greetings,
>
> Andres Freund
>