Re: function calls optimization

Hi,

On October 31, 2019 7:45:26 AM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Andres Freund <andres(at)anarazel(dot)de> writes:
>> On October 31, 2019 7:06:13 AM PDT, Andrzej Barszcz
><abusinf(at)gmail(dot)com> wrote:
>>> I almost finished patch optimizing non volatile function calls.
>>>
>>> select f(t.n) from t where f(t.n) > 10 and f(t.n) < 100; needs 3
>calls
>>> of
>>> f() for each tuple,
>>> after applying patch only 1.
>>>
>>> Any pros and cons ?
>
>> Depends on the actual way of implementing this proposal. Think we
>need more details than what you idea here.
>
>We've typically supposed that the cost of searching for duplicate
>subexpressions would outweigh the benefits of sometimes finding them.

Based on profiles I've seen I'm not sure that's the right choice. Both for when the calls are expensive (say postgis stuff), and for when a lot of rows are processed.

I think one part of doing this in a realistic manner is an efficient search for redundant expressions. The other, also non trivial, is how to even represent references to the results of expressions in other parts of the expression tree / other expressions.

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