Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: James Coleman <jtc331@gmail.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: David Rowley <dgrowleyml@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-08-19T07:16:17Z
Lists: 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
Commits
-
Use a hash table to speed up NOT IN(values)
- 29f45e299e7f 15.0 landed
-
Speedup ScalarArrayOpExpr evaluation
- 50e17ad281b8 14.0 landed