Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
James Coleman <jtc331@gmail.com>
From: James Coleman <jtc331@gmail.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: David Rowley <dgrowleyml@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-05-01T02:20:39Z
Lists: pgsql-hackers
Attachments
- v3-0003-Try-simple-hash.patch (text/x-patch) patch v3-0003
- v3-0002-Try-using-dynahash.patch (text/x-patch) patch v3-0002
- v3-0001-Binary-search-const-arrays-in-OR-d-ScalarArrayOps.patch (text/x-patch) patch v3-0001
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. James
Commits
-
Use a hash table to speed up NOT IN(values)
- 29f45e299e7f 15.0 landed
-
Speedup ScalarArrayOpExpr evaluation
- 50e17ad281b8 14.0 landed