postgresql – Postgres数组重叠(\u0026\u0026)运算符可以使用索引吗?

前端之家收集整理的这篇文章主要介绍了postgresql – Postgres数组重叠(\u0026\u0026)运算符可以使用索引吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们有一个带有索引数组列的表:
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)表示索引支持&&amp ;.

我在Postgresql 9.2中构建了一个类似的表;区别在于使用GIN(动词);出于某种原因,我似乎没有在此上下文中提供int_ops.我加载了几千行随机(ish)数据.

设置enable_seqscan off让Postgresql使用索引.

Postgresql计算出顺序扫描的成本低于位图堆扫描的成本.顺序扫描的实际时间是位图堆扫描的实际时间的10%,但顺序扫描的总运行时间略大于位图堆扫描的总运行时间.

原文链接:https://www.f2er.com/postgresql/191895.html

猜你在找的Postgre SQL相关文章