postgresql与多列的btree查询优化

-1

我有一个在多个键上有一个btree索引的大表。如果通过修复索引的前两列并在第三列上放置单边界来进行查询，则即使匹配行的数量非常低，也会导致非常慢的查询。如果我在第三列上添加双向绑定，则查询速度会更快。查看下面的代码片段。postgresql与多列的btree查询优化

我希望postgresql应该能够快速找到一个索引列的下限，但在这种情况下，它似乎不是。

你能解释为什么我会遇到这个问题吗？如何解决它？

> select min(minute) from data_minutesample where probe_id = 19 and power = 0 and minute between 0 and 22780323; 
    min  
---------- 
22780262 
(1 row) 

Time: 28233.498 ms 

> select min(minute) from data_minutesample where probe_id = 19 and power = 0 and minute between 22780000 and 22780323; 
    min  
---------- 
22780262 
(1 row) 

Time: 13.946 ms 

> \d+ data_minutesample 
      Table "public.data_minutesample" 
[...] 
Indexes: 
    "data_minutesample_index_unique" UNIQUE, btree (probe_id, power, minute, proto_id, src_port, dst_port, src_addr, dst_addr)

来源

2013-05-26 Emanuele Paolini

填充表格后，您是否运行过'vacuum analyze'？ – wildplasser

所有这些都应该在你的问题中没有我要求：PostgreSQL的版本，表定义，基数，计时方法（包括数据传输？），EXPLAIN ANALYZE的输出，最好发布到explain.depesz.com。 –

尝试增加EXPLAIN每个查询的开始，这样就可以看到查询规划是如何决定执行它们。

我的猜测是，第一个决定不使用索引，而是做一个表扫描，因为你选择了一个大范围的值。它可能没有意识到在该范围内实际上只有一个匹配值。

您可能会发现在表格上运行ANALYZE以确保规划者具有最新的统计信息，这将有助于制定更好的决策。

来源

2013-05-26 17:44:22 TomH

postgresql与多列的btree查询优化

回答

相关问题