Thomas Kellerer <spam_ea...@gmx.net> writes:
> While testing a query on an integer array with a GIN index, I stumbled over a
> behaviour which surprised me and which I would consider a bug - but maybe I
> am wrong.
It's not a bug --- the problem is that that operator is capturing your
query reference, and it's not a member of the opclass for the index
you have, so no index scan for you.
> The above happens even if the intarray extension is a the end of the search
> path, e.g. "set search_path = public, intarray".
Yeah, because it's an exact datatype match while the core operator
is anyarray && anyarray which is not.
Ideally, perhaps, the extension could add its operator to the core
gin-arrays opclass, but we lack any reasonable way to manage that.
Something that's maybe more likely to happen is to remove that
operator from the extension altogether; but that will break things
for some people too, no doubt :-(
regards, tom lane
