Sorry, as a final follow up here, another option (should anyone run into
this and want to keep the intarray extension) is to create the index using
the gin__int_ops operator:
CREATE INDEX ON sets USING GIN(obj_id gin__int_ops);
On Sun, Aug 20, 2017 at 4:22 PM, Wells Oliver
wrote:
> YES!
>
> \dx
YES!
\dx yields intarray was installed (back in the 9.1 days, maybe) and that
was clobbering the @> operator.
Looking into the implications of removing intarray now that we're at 9.6,
seems harmless, but will do my due diligence.
Thanks Jeff.
On Sun, Aug 20, 2017 at 3:15 PM, Jeff Janes wrote
On Sun, Aug 20, 2017 at 1:28 PM, Wells Oliver
wrote:
>
> Why is this happening and what can I do to get my GIN indexes working?
> Thanks!
>
>
What extensions do you have installed in each database? I bet one of them
(like intarray) redefines @> for one of your databases.
Try fully qualifying th
Hey guys, I hope you can help. I am trying to use a GIN Index on an array
column and, weirdly, on the exact same server (9.6.3) it uses the index on
one database, and not on the other. Here's the test query I am using:
CREATE TEMPORARY TABLE objs (obj_id integer PRIMARY KEY);
CREATE TEMPORARY TABL
