Thomas Kellerer <spam_eater@xxxxxxx> 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
