On 2018-10-30 16:23:37 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > How did you deal with the fact that we might extract subset of the LET()
> > into e.g. a RestrictionInfo (and then e.g. an IndexPath), but another
> > part would be e.g. evaluated as part of a qual?
>
> Well, a Lambda expression is not something that can be optimized away
> (unless perhaps you can get rid of the need for any of its output Params)
> so I don't see how any of its subexpressions would ever wind up split out
> from inside it.
Isn't that a pretty fundamental requirement for the postgis (and I
presume lots of other) usecases? What they have is wrapper function
functions like ST_DWithin(geometry, geometry, float) that roughly expand
to something (simplified) like
SELECT $1 && ST_Expand($2, $3) AND _ST_DWithin($1, $2, $3);
where && is the overlaps operator, and then _ST_DWithin is the accurate
computation. That allows a quick bounding-box (or similar) search via
index, and then an accurate re-check. But $2 might be the result of a
function (with constant input), and that'll currently prevent the SQL
function from being inlined when the function is expensive. And the
postgis folks *want* its functions be marked expensive, because they
really are - but getting index searches is also important.
Am I missing something, or how would what you propose not break that?
(delaying answering to the rest until we cleared up the above)
Greetings,
Andres Freund
