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
