Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: James Coleman <jtc331@gmail.com>,
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-08T01:16:49Z
Lists: pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes: > On Sat, 8 May 2021 at 09:15, James Coleman <jtc331@gmail.com> wrote: >> On Sat, Apr 24, 2021 at 6:25 AM David Rowley <dgrowleyml@gmail.com> wrote: >>> I'm a bit undecided if it's safe to set the opfuncid to the negator >>> function. If anything were to set that again based on the opno then >>> it would likely set it to the wrong thing. We can't go changing the >>> opno either because EXPLAIN would display the wrong thing. >> I don't personally see a reason why this is a problem. But I also >> don't know that I have enough knowledge of the codebase to say that >> definitively. > The reason for my concern is that if the opfuncid is set to > InvalidOid, set_sa_opfuncid() always sets the ScalarArrayOpExpr's > opfuncid to get_opcode(opexpr->opno). I will personally veto any design that involves setting opfuncid to something that doesn't match the opno. That's just horrid, and it will break something somewhere, either immediately or down the road. 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. regards, tom lane
Commits
-
Use a hash table to speed up NOT IN(values)
- 29f45e299e7f 15.0 landed
-
Speedup ScalarArrayOpExpr evaluation
- 50e17ad281b8 14.0 landed