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查詢優化

回答

相關問題