Re: [GENERAL] A question on GIN indexes and arrays - Mailing list pgsql-general

From Wells Oliver
Subject Re: [GENERAL] A question on GIN indexes and arrays
Date
Msg-id CAOC+FBWxFFR65Q6sSqAyQ6kgxZTPVL37FZtN8pXWF1iAYH1AuQ@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] A question on GIN indexes and arrays  (Wells Oliver <wells.oliver@gmail.com>)
List pgsql-general
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 <wells.oliver@gmail.com> wrote:
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 <jeff.janes@gmail.com> wrote:
On Sun, Aug 20, 2017 at 1:28 PM, Wells Oliver <wells.oliver@gmail.com> 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 the operator.  OPERATOR(pg_catalog.@>)

Cheers,

Jeff



--



--

pgsql-general by date:

Previous
From: Wells Oliver
Date:
Subject: Re: [GENERAL] A question on GIN indexes and arrays
Next
From: Alexander Farber
Date:
Subject: Re: [GENERAL] make postgresql 9.5 default on centos 7