Re: [GENERAL] A question on GIN indexes and arrays

Поиск
Список
Период
Сортировка
От Wells Oliver
Тема Re: [GENERAL] A question on GIN indexes and arrays
Дата
Msg-id CAOC+FBWxFFR65Q6sSqAyQ6kgxZTPVL37FZtN8pXWF1iAYH1AuQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] A question on GIN indexes and arrays  (Wells Oliver <wells.oliver@gmail.com>)
Список 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 по дате отправления: