From: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Overloaded && operator from intarray module prevents index usage. |
Date: | 2019-02-28 20:38:14 |
Message-ID: | 0adbbf65-d596-bb45-b58a-95e08517c699@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Rob Sargent | 2019-02-28 20:56:40 | Re: specifying table in function args |
Previous Message | chiru r | 2019-02-28 20:28:15 | Re: Pgbackrest Comparability issue |