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

From Tom Lane
Subject Re: Inlining functions with "expensive" parameters
Date
Msg-id 2309.1511276659@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inlining functions with "expensive" parameters  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Inlining functions with "expensive" parameters
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Nov 16, 2017 at 2:51 PM, Andres Freund <andres@anarazel.de> wrote:
>> 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 don't quite follow the need for this.  I mean, if we just stick a
> Param reference in there and create a corresponding InitPlan, the
> Param will be evaluated on demand, right?  Is the point of the new
> node to make sure that the Param gets re-evaluated when needed?

Yeah.  By default, an initplan is only going to be evaluated once per
query, not once per row.  It's possible that you could set up Param
dependencies to force the correct semantics, but that would be more
complicated, and probably less performant, than introducing a new
expression node type.  Also, I'm dubious that it could be made to work
at all for standalone expression evaluation; Param-driven re-evaluation
is only considered when running a plan tree.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Inlining functions with "expensive" parameters
Next
From: Tom Lane
Date:
Subject: Re: Inlining functions with "expensive" parameters