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
