Czy operator nakładający się na Postgres (&&) może używać indeksu?

Question

Mamy tabelę z kolumną tablicy indeksowanej:

CREATE TABLE mention (
    id SERIAL, 
    phraseIds integer[], 
    PRIMARY KEY (id) 
); 
CREATE INDEX indx_mentions_phraseIds on mention USING GIN (phraseids public.gin__int_ops); 

Zapytania za pomocą „nachodzi” operator w tej kolumnie nie wydają się korzystać z indeksu:

explain analyze select m.id FROM mention m WHERE m.phraseIds && ARRAY[11638,11639]; 

Seq Scan on mention m (cost=0.00..933723.44 rows=1404 width=4) (actual time=103.018..3751.525 rows=1101 loops=1) 
Filter: (phraseids && '{11638,11639}'::integer[]) 
Rows Removed by Filter: 7019974 
Total runtime: 3751.618 ms 

Czy to możliwe, aby uzyskać PostgreSQL do korzystania z indeksu? A może powinniśmy robić coś innego?

Aktualizacja: powtórzyłem test z "SET enable_seqscan TO off", a indeks nadal nie jest używany.

Aktualizacja: Powinienem wspomnieć, że używam 9.2 z rozszerzeniem intarray.

Aktualizacja: Wygląda na to, że rozszerzenie typu intarray jest częścią tego problemu. Ponownie utworzyłem tabelę bez użycia rozszerzenia intarray, a indeks jest używany zgodnie z oczekiwaniami. Czy ktoś wie, jak uzyskać indeks do użycia z rozszerzeniem intarray? Dokumenty (http://www.postgresql.org/docs/9.2/static/intarray.html) mówią, że indeksy są obsługiwane dla & &.

Answer 1

Zbudowałem podobną tabelę w PostgreSQL 9.2; różnica była USING GIN (phraseids); Nie wydaje się mieć int_ops dostępne w tym kontekście z jakiegoś powodu. Załadowałem kilka tysięcy wierszy losowych danych (ish).

Ustawienie enable_seqscan off let postgreSQL użyj indeksu.

PostgreSQL obliczył, że koszt skanowania sekwencyjnego jest mniejszy niż koszt skanowania sterty bitmap. Rzeczywisty czas skanowania sekwencyjnego wynosił 10% rzeczywistego czasu skanowania sterty bitmap, ale całkowity czas wykonania skanowania sekwencyjnego był nieco dłuższy niż całkowity czas skanowania sterty bitmap.