Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
От | Heikki Linnakangas |
---|---|
Тема | Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays |
Дата | |
Msg-id | 6f62a5c3-6bb3-dead-9e58-d7f3bb3c8e6f@iki.fi обсуждение исходный текст |
Ответ на | Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays (James Coleman <jtc331@gmail.com>) |
Ответы |
Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
|
Список | pgsql-hackers |
On 01/05/2020 05:20, James Coleman wrote: > On Tue, Apr 28, 2020 at 8:25 AM Tomas Vondra > <tomas.vondra@2ndquadrant.com> wrote: > ... >> Any particular reasons to pick dynahash over simplehash? ISTM we're >> using simplehash elsewhere in the executor (grouping, tidbitmap, ...), >> while there are not many places using dynahash for simple short-lived >> hash tables. Of course, that alone is a weak reason to insist on using >> simplehash here, but I suppose there were reasons for not using dynahash >> and we'll end up facing the same issues here. > > I've attached a patch series that includes switching to simplehash. > Obviously we'd really just collapse all of these patches, but it's > perhaps interesting to see the changes required to use each style > (binary search, dynahash, simplehash). > > As before, there are clearly comments and naming things to be > addressed, but the implementation should be reasonably clean. Looks good, aside from the cleanup work that you mentioned. There are a few more cases that I think you could easily handle with very little extra code: You could also apply the optimization for non-Const expressions, as long as they're stable (i.e. !contain_volatile_functions(expr)). Deconstructing the array Datum into a simple C array on first call would be a win even for very small arrays and for AND semantics, even if you don't use a hash table. - Heikki
В списке pgsql-hackers по дате отправления: