緩慢的查詢與良好的計劃

我們有兩個服務器，最新的將取代最老的一個。除了單個查詢之外，它們在性能上幾乎相同。在兩個不同的服務器（相同的數據庫定義，相同的數據，僅從頭開始重建的索引）中的相同查詢花費了更多時間在最新的實例中。緩慢的查詢與良好的計劃

這兩個計劃都是相同的，並且qwery很簡單：

Nested Loop (cost=0.00..17.83 rows=1 width=2262) (actual time=0.032..0.032 rows=0 loops=1) 
    Buffers: shared hit=3 
    -> Index Scan using psan_para_fk_ix on parasetana a0 (cost=0.00..9.48 rows=1 width=1735) (actual time=0.030..0.030 rows=0 loops=1) 
     Index Cond: (((ca)::text = 'r'::text) AND (idp = 36678502::numeric)) 
     Filter: (flg = '1'::bpchar) 
     Buffers: shared hit=3 
    -> Index Scan using seta_pk on seta a1 (cost=0.00..8.33 rows=1 width=527) (never executed) 
     Index Cond: (((a1.ca)::text = 'r'::text) AND (a1.idgrla = a0.idgrla) AND (a1.prog = a0.prog_set)) 
     Filter: (a1.flgp = '0'::bpchar) 
Total runtime: 0.153 ms 
(10 rows)

時間：2217.074毫秒

正如你所看到的，總的運行時間爲0.2ms。新舊服務器都是如此。但在舊服務器中的時間是30ms，在新的服務器中是200倍（2.2秒比30毫秒）

什麼會導致這種差異？ PostgreSQL的醫生說，在select語句總運行時間和時間應該是幾乎一樣的...

感謝

來源

2015-05-13 Wishper

您是否分析過或清理過有問題的表格？ – ntalbs

是的，都是。表btw是從另一個服務器中的轉儲創建的，所以它應該從一開始就是最佳的。 – Wishper

據我所知，這是一個簡單的加入使用嵌套循環與適當的索引。問題應該是由於第二個（大）表的緩存不好造成的。這裏可能第二張表與所使用的索引有很大的關聯。嘗試使用CLUSTER命令查看是否有幫助。

你也可以嘗試改變計劃。您可能需要的選項 - 交換連接順序，使用散列連接。

來源

2015-05-13 09:08:27 Matt

緩存時間是否佔總運行時間（0.153 ms）？該文檔指出總運行時間「不包括解析，重寫或計劃時間」[http://www.postgresql.org/docs/9.3/static/using-explain.html] 此外，什麼可以改變緩存策略兩臺服務器？ – Wishper

緩慢的查詢與良好的計劃

回答

相關問題