Приветствую.

Есть таблица с полем agg_series_id. Тип поля integer[]. По полю создан индекс, примерно так: CREATE INDEX idx_intarray ON some_tbl USING GIN (agg_series_id gin__int_ops). В таблице примерно 500к строк.

Проблема: для запроса SELECT count(*) FROM web.item_search WHERE agg_series_id @> ARRAY [1] - план будет такой:

Aggregate (cost=129835.91..129835.92 rows=1 width=8)
-> Seq Scan on some_tbl (cost=0.00..129835.89 rows=11 width=0)
Filter: (agg_series_id @> '{1}'::integer[])

set enable_seqscan=off, vacuum analyze и увеличение статистики на поле эффекта не дают - план все равно останется с seqscan. Но если индекс создать не `intarray`, т.е. без gin__int_ops - CREATE INDEX idx_test ON some_tbl USING GIN (agg_series_id) - то план меняется на использование вот этого обычного индекса:

Aggregate (cost=55.93..55.94 rows=1 width=8)
-> Bitmap Heap Scan on materialize_item_search_1520832700 (cost=12.08..55.91 rows=11 width=0)
Recheck Cond: (agg_series_id @> '{1}'::integer[])
-> Bitmap Index Scan on test_index_agg_series_id_array2 (cost=0.00..12.08 rows=11 width=0)
Index Cond: (agg_series_id @> '{1}'::integer[])

Косты становятся нормальные. Собственно вопрос: почему индекс по `intarray` может не использоваться при запросе, а индекс по обычному array - используется? В интернете ничего не нашел. Более того, в таблице еще несколько полей integer[] и по ним такая же ситуация - специальный индекс intarray не используется никак, а обычный используется.

Я бы и удалил индексы intarray, создав обычные, но боюсь, что после какого-нибудь обновления pg эта логика изменится и обычные gin индексы наоборот не будут использоваться, а нужны будут intarray. Пока это отловишь - пройдет какое-то время.

На SO написали в комменте, что простой GIN индекс поддерживает @> оператор, но зачем тогда вообще нужен gin__int_ops?

Из доки pg: intarray provides index support for the &&, @>, <@, and @@ operators ( https://www.postgresql.org/docs/9.6/static/intarray.html ). Или какой-то другой оператор имелся в виду?

qwwqответить на вопрос религия запрещает ?

Вопрос "куда ставили интеррей"? Я его не понимаю. Ставили куда - на сервер, в запрос, в индекс, в схему?

qwwqthey work only on integer arrays that do not contain nulls, while the built-in operators work for any array type

Т.е. то, что поле nullable, автоматически означает, что с индексом gin__int_ops планировщик работать не будет, т.к. оператор @> будет по обычному массиву, а не интарреевский?

qwwqавторThe operators &&, @> and <@ are equivalent to PostgreSQL's built-in operators of the same names, except that they work only on integer arrays that do not contain nulls, while the built-in operators work for any array type. но немного другие.

Я проверил: поле not null и в массивах полей null не встречается. Как тогда определить - какого типа @> оператор используется?

Все, разобрался - оператор был в другой схеме. Спасибо.