Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: James Coleman <jtc331@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Tomas Vondra <tomas.vondra@enterprisedb.com>, Michael Paquier <michael@paquier.xyz>, Andrew Dunstan <andrew@dunslane.net>,
Peter Geoghegan <pg@bowt.ie>, Heikki Linnakangas <hlinnaka@iki.fi>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-05-08T02:04:24Z
Lists: pgsql-hackers
On Sat, 8 May 2021 at 13:37, James Coleman <jtc331@gmail.com> wrote: > > On Fri, May 7, 2021 at 9:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I don't immediately see why you can't add an "invert" boolean flag to > > ScalarArrayOpExpr and let the executor machinery deal with this. That'd > > have the advantage of not having to depend on there being a negator. > > Don't we need to have a negator to be able to look up the proper has > function? At least somewhere in the process you'd have to convert from > looking up the <> op to looking up the = op and then setting the > "invert" flag. Yeah, we *do* need to ensure there's a negator in the planner as we need to use it during hash probes. It's no good checking the hash bucket we landed on does match with the <> operator's function. We won't find many matches that way! I'm not opposed to adding some new field if that's what it takes. I'd imagine the new field will be something like negfuncid which will be InvalidOid unless the hash function is set and useOr == false David
Commits
-
Use a hash table to speed up NOT IN(values)
- 29f45e299e7f 15.0 landed
-
Speedup ScalarArrayOpExpr evaluation
- 50e17ad281b8 14.0 landed