Greenplum 自動統計資訊收集 - 暨統計資訊不準引入的broadcast motion一例

PostgreSQL , Greenplum , 統計資訊 , 自動統計資訊 , broadcast motion , 執行計劃

資料庫執行計劃的好壞，與資料庫的SQL優化器息息相關。Greenplum有兩套優化器，legacy query optimizer 與 ORCA。

這兩個優化器都是CBO優化器，都需要依賴統計資訊，如果統計資訊不準确，可能生成的執行計劃就不準确。

例如我們有一個這樣的QUERY，發現怎麼跑都跑不出來。

觀察執行計劃，發現有一個節點用到了broadcast motion，也就是廣播。

當JOIN字段并非分布鍵時，Greenplum會根據表的大小，選擇重分布或廣播。（小表廣播，大表的話多階段JOIN）。

<a href="https://github.com/digoal/blog/blob/master/201711/20171123_01.md">《HybridDB PostgreSQL "Sort、Group、distinct 聚合、JOIN" 不懼怕資料傾斜的黑科技和原理 - 多階段聚合》</a>

而這個執行計劃跑偏的SQL，恰恰是在一個大表上觸發了廣播(broadcast motion)，這不正常。

查詢pg_class，值有1條記錄，占用0個BLOCK

執行analyze，收集統計資訊，執行計劃恢複。

(Greenplum對于超級大表，收集統計資訊時，會建構臨時表來進行采樣分析)

收集統計資訊後，執行計劃恢複，沒有broadcast了，執行也秒級傳回了。

對于在函數内 或 函數外執行DML時，核心會跟蹤表的記錄數變更影響的資料量，我們可以設定什麼時候收集統計資訊：

none：不收集

on_no_stats：沒有統計資訊時，收集

on_change：當寫入、更新量超過門檻值（gp_autostats_on_change_threshold參數設定的行數，預設為20億）後，自動收集統計資訊。

為了讓資料庫産生準确的執行計劃，建議要麼使用者自己排程analyZE收集統計資訊，要麼自動收集。