Re: function calls optimization - Mailing list pgsql-hackers

From Andres Freund
Subject Re: function calls optimization
Date
Msg-id 668AB6FB-A831-4B63-81D9-3A136232B41C@anarazel.de
Whole thread Raw
In response to Re: function calls optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: function calls optimization  (Andres Freund <andres@anarazel.de>)
Re: function calls optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On October 31, 2019 7:45:26 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Andres Freund <andres@anarazel.de> writes:
>> On October 31, 2019 7:06:13 AM PDT, Andrzej Barszcz
><abusinf@gmail.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
nontrivial, is how to even represent references to the results of expressions in other parts of the expression tree /
otherexpressions. 

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: function calls optimization
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench - extend initialization phase control