From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrzej Barszcz <abusinf(at)gmail(dot)com>,pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: function calls optimization |
Date: | 2019-10-31 15:02:48 |
Message-ID: | EC3B2F1D-A065-445F-A028-50E2677844B8@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
On October 31, 2019 7:53:20 AM PDT, Andres Freund <andres(at)anarazel(dot)de> wrote:
>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.
>
>I think one part of doing this in a realistic manner is an efficient
>search for redundant expressions.
One way to improve the situation - which is applicable in a lot of situations, e.g. setrefs.c etc - would be to compute hashes for (sub-) expression trees. Which makes it a lot easier to bail out early when trees are not the same, and also easier to build an efficient way to find redundant expressions. There's some complexity in invalidating such hashes once computed, and when to first compute them, obviously.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Karlsson | 2019-10-31 15:05:28 | Re: function calls optimization |
Previous Message | Ibrar Ahmed | 2019-10-31 14:54:25 | Re: [BUG] Partition creation fails after dropping a column and adding a partial index |