postgresql - postgres: why isn't this query using the GIN index on the array value? -

sql:

create temporary table objs (obj_id integer); create temporary table sets (obj_id integer[], somecount smallint);  insert objs select generate_series(0,10000); insert sets     select array[p1.obj_id, p2.obj_id,p3.obj_id], generate_series(0,100)     objs p1     cross join objs p2     cross join objs p3     p2.obj_id = p1.obj_id + 1 , p3.obj_id = p2.obj_id + 1;  create index on sets using gin(obj_id); set enable_seqscan = off; explain analyze select * sets obj_id @> array[1,2]::integer[]; 

yields:

                                                       query plan                                                        ------------------------------------------------------------------------------------------------------------------------  seq scan on sets  (cost=10000000000.00..10000021039.74 rows=25 width=34) (actual time=0.037..333.496 rows=202 loops=1)    filter: (obj_id @> '{1,2}'::integer[])    rows removed filter: 1009697  planning time: 0.727 ms  execution time: 333.529 ms (5 rows) 

why doing sequence scan , not using index?

update

running on 1 db on server uses bitmap heap scan on index (great!) , running not (boo!) , don't know why. same server, different databases.

the postgres extension intarray installed in database used sequential scan, clobbering @> operator. 3 options:

1. changing call operator(pg_catalog.@>) uses in gin index.

2. create index using gin__int_ops option: create index on sets using gin(obj_id gin__int_ops);

3. remove intarray extension (but require elsewhere, nope)