Greenplum查詢計劃評估

如何看查詢計劃?

　　若一個查詢表現出不好的性能，查看查詢計劃可能有助於找到問題點。下面是 一些須要查看的東西： 

計劃中是否有一個操做花費時間超長？

　　查詢計劃中是否有一個操做花費 了大部分的處理時間？例如，若是一個索引掃描比預期的時間超長，也許 該索引已經處於過時狀態，須要考慮重建索引。還可臨時嘗試使用enable_ 之類的參數查看是否能夠強制選擇不一樣的計劃(可能會更好的效果)，這些 參數能夠設置特定的查詢計劃操做爲開啓或關閉狀態。 

規劃器的評估是否接近實際狀況？

　　執行EXPLAIN ANALYZE查看規劃器 評估的記錄數與真實運行查詢操做返回的記錄數是否一致。若是差別巨大， 可能須要在TABLE相關的COLUMN上收集更多的統計信息。 

選擇性強的條件是否較早出現？

　　選擇性強的條件應該被較早應用，從而使 得在計劃樹中上傳的記錄更少。若是查詢計劃在選擇性評估方面沒有對查 詢條件做出正確的判斷，可能須要在TABLE相關的COLUMN上收集更多 的統計信息。相關信息可查看」維護數據庫統計信息」章節。也能夠嘗試調 整SQL語句WHERE子句的順序。 

規劃器是否選擇了最佳的關聯順序？

　　如查詢使用多表關聯，須要確保規劃 器選擇了選擇性最好的關聯順序。那些能夠消除大量記錄的關聯應在更早 的被執行，從而使得在計劃樹中上傳的記錄更少。若是規劃器沒有選擇最 佳的關聯順序，能夠嘗試設置join_collapse_limit=1並在SQL語句中構造特 定的關聯順序，從而能夠強制規劃器選擇指定的關聯順序。還能夠嘗試在 TABLE相關的COLUMN上收集更多的統計信息。相關信息可查看」維護數

規劃器是否選擇性的掃描分區表？

　　若是使用了分區，規劃器是否值掃描了 查詢條件匹配的相關子表？父表的掃描返回0條記錄(本該如此，由於父表 不包含任何數據)。做爲顯示選擇性掃描分區查詢計劃的例子。 

規劃器是否合適的選擇了HASH聚合與HASH關聯操做？

　　HASH操做一般 比其餘類型的關聯和聚合要快。記錄在內存中的比較排序比磁盤快。要使 用HASH操做，必須有足夠的工做內存用以放置評估的記錄。對於特定才 查詢能夠嘗試增長工做內存來查看是否可以得到更好的性能。若是可能， 爲該查詢執行EXPLAIN ANALYZE，將能夠獲得哪些操做緩存到磁盤(由 於工做內存不足致使)，多少的工做內存被使用，以及須要多少內存以保證 不緩存到磁盤。例如：

Work_mem used: 23430K bytes avg, 23430K bytes max (seg0).

Work_mem wanted: 33649K bytes avg, 33649K bytes max (seg0) to lessen

workfile I/O affecting 2 workers.

須要注意的是wanted信息只是一個提示，基於寫出工做文件的量是不精確的。 須要的最小work_mem可能會比提示的值或多或少一些。