Re: function calls optimization

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org,Andrzej Barszcz <abusinf(at)gmail(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: function calls optimization
Date: 2019-10-31 14:53:20
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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
>>> 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.

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2019-10-31 14:54:00 Re: pgbench - extend initialization phase control
Previous Message Tom Lane 2019-10-31 14:45:26 Re: function calls optimization