Postgres配列の重複（&&）演算子でインデックスを使用できますか？

Question

私たちは、インデックス付きの配列の列を持つテーブルがある：このコラムの「重複」演算子を使用して

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

クエリはインデックスを使用していないようです：

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 

は、それが取得することは可能ですPostgreSQLはインデックスを使用する？あるいは何か他のことをしなければならないのでしょうか？

更新：「SET enable_seqscan TO off」でテストを繰り返しましたが、インデックスはまだ使用されていません。

アップデート：私は、9.2をintarray拡張子とともに使用していることを述べておきます。

更新：intarray拡張がこの問題の一部であるようです。私はintarray拡張子を使用せずにテーブルを再作成し、インデックスは期待どおりに使用されます。誰でも、インデックスをintarray拡張子とともに使用する方法を知っていますか？ドキュメント（http://www.postgresql.org/docs/9.2/static/intarray.html）は、インデックスは& &でサポートされていると言います。

Answer 1

私はPostgreSQL 9.2で同様のテーブルを構築しました。違いはUSING GIN (phraseids);でした。私は何らかの理由でこのコンテキストで利用可能なint_opsを持っていないようです。私は数千行のランダム（ish）データをロードしました。

enable_seqscanをoffに設定すると、PostgreSQLはインデックスを使用します。

PostgreSQLは、順次スキャンのコストをビットマップヒープスキャンのコストよりも低く計算しました。シーケンシャルスキャンの実際の時間は、ビットマップヒープスキャンの実際の時間の10％でしたが、シーケンシャルスキャンの合計実行時間は、ビットマップヒープスキャンの合計実行時間より少し多かったです。