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> |
Subject: | Re: function calls optimization |
Date: | 2019-10-31 15:06:50 |
Message-ID: | 19586.1572534410@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:45:26 AM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
Yeah, if your mental model of a function call is some remarkably expensive
PostGIS geometry manipulation, it's easy to justify doing a lot of work
to try to detect duplicates. But most functions in most queries are
more like int4pl or btint8cmp, and it's going to be extremely remarkable
if you can make back the planner costs of checking for duplicate usages
of those.
Possibly this could be finessed by only trying to find duplicates of
functions that have high cost estimates. Not sure how high is high
enough.
> 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 re eferences to the results of expressions in other parts of the expression tree / other expressions.
Yup, both of those would be critical to do right.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-10-31 15:20:39 | Re: function calls optimization |
Previous Message | Andreas Karlsson | 2019-10-31 15:05:28 | Re: function calls optimization |