| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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:45:26 |
| Message-ID: | 18500.1572533126@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-10-31 14:53:20 | Re: function calls optimization |
| Previous Message | Andres Freund | 2019-10-31 14:25:06 | Re: function calls optimization |