Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
James Coleman <jtc331@gmail.com>
From: James Coleman <jtc331@gmail.com>
To: David Rowley <dgrowleyml@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-08T01:49:50Z
Lists: pgsql-hackers
On Fri, May 7, 2021 at 8:38 PM David Rowley <dgrowleyml@gmail.com> wrote:
>
> It's important to think of other cases, I just don't think there's any
> need to do anything for that one. Remember that we have the
> restriction of requiring a set of Consts, so for that case to be met,
> someone would have to write something like: col =
> ALL('{1,1,1,1,1,1,1,1}'::int[]); I think if anyone comes along
> complaining that a query containing that is not as fast as they'd like
> then we might tell them that they should just use: col = 1. A sanity
> checkup might not go amiss either.
I wasn't concerned with trying to optimize this case (I don't think we
can anyway, at least not without adding new work, like de-duplicating
the array first). Though I do hope that someday I'll/we'll get around
to getting the stable subexpressions caching patch finished, and then
this will be able to work for more than constant arrays.
I just wanted to confirm we'd thought through the cases we can't
handle to ensure we're not accidentally covering them.
James
Commits
-
Use a hash table to speed up NOT IN(values)
- 29f45e299e7f 15.0 landed
-
Speedup ScalarArrayOpExpr evaluation
- 50e17ad281b8 14.0 landed