Re: Inlining functions with "expensive" parameters - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Inlining functions with "expensive" parameters
Date
Msg-id AD7DA78B-65B6-4EC9-BCA7-DCB16A89B88B@anarazel.de
Whole thread Raw
In response to Re: Inlining functions with "expensive" parameters  (Paul Ramsey <pramsey@cleverelephant.ca>)
List pgsql-hackers

On November 17, 2017 5:15:57 AM PST, Paul Ramsey <pramsey@cleverelephant.ca> wrote:
>On Thu, Nov 16, 2017 at 12:37 PM, Andres Freund <andres@anarazel.de>
>wrote:
>
>> Hi,
>>
>> On 2017-11-16 15:27:59 -0500, Tom Lane wrote:
>> > Andres Freund <andres@anarazel.de> writes:
>> > > On November 16, 2017 11:44:52 AM PST, Tom Lane
><tgl@sss.pgh.pa.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!

Oh, I wasn't planning to work in this anytime soon. From my end this was just spitballing how a solution might look
like.

If you want to take a stab...

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)
Next
From: Vladimir Rusinov
Date:
Subject: Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)