GreenPlum環境： 1臺 master host（記憶體：16G）， 2臺segment host（每臺 2 segments，記憶體：16G）， 版本：5.3.0
postgresql環境： 1臺（硬體同GreenPlum的配置），版本：8.3.23
表： alert_log_sm_http 在pg與gp的大小相同，行數為：5000000行，ID為主鍵索引。
運行結果如下：
PG：
GP：
問題：
運行時間相差太大，分別為：PG：0.056ms，GP：1974.565ms。從explain的分析結果看，segmet做全表掃描的時間消耗太大。
這樣的問題可以怎么解決？
uj5u.com熱心網友回復：
再跑一次， 可能一個是冷資料一個是熱資料uj5u.com熱心網友回復：
基本找到原因了： optimizer 的原因，我們走不走索引由它決定，而有時候它的優化會偏離我們的方向，比如上面GP的運行走索引的話，效率會高很多，而它卻不走索引。解決辦法： 關掉 optimizer。
uj5u.com熱心網友回復：
一眼就看到pg走的索引。。。。。uj5u.com熱心網友回復：
可以關注下Greenplum的統計資訊收集是否正確uj5u.com熱心網友回復：
GP影響查詢的因素：1.是否有統計資訊
2.是否有索引
3.資料分布是否均勻
這些都是需要考慮的地方
而且GP在優化器方面有做優化，但不穩定，需要測驗
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/88026.html
標籤：Greenplum
下一篇：關于兩個表的聯合查詢問題