Michael Lewis schrieb am 28.02.2019 um 21:23:
Yeah, because it's an exact datatype match while the core operator is anyarray && anyarray which is not.Can you dumb down how to change the index or column type such that an index will be used for the && operator while intarray extension is installed? We have the intarray extension installed and I doubt that I can get it removed. I've added gin index on a column declared as type "integer array" and had expected the index to be used, but I did not test it yet since there is some bad data with NULLs stored as a value in the integer array and I am waiting on that data cleanup to be done before directly using && operator. I expect that when I do test it, I will be impacted by this same concern. It is simplest to change the column type from integer array to anyarray? Is there a con to doing so?
I see two options: create the gin index with the opclass provided by intarray: create index ... using gin (... gin__int_ops); Or if you use the regular opclass for the GIN index, make sure to use the built-in operator, e.g.: OPERATOR(pg_catalog.&&) instead of && or OPERATOR(pg_catalog.@>) instead of @> Thomas
