作為開源資料庫的新手，近日有興對比了Pg和MySQL的查詢計劃。 通過Pg源碼目錄下的src\backend\executor\README文件，加上一些簡單調試，就能對Pg的執行機制產生一個初步印象；而MySQL的代碼可讀性比Pg差了不少，可能還要花些時日去瞭解先。 原本想寫一篇執行機制對比的文章 ...
作為開源資料庫的新手，近日有興對比了Pg和MySQL的查詢計劃。
通過Pg源碼目錄下的src\backend\executor\README文件，加上一些簡單調試，就能對Pg的執行機制產生一個初步印象；
而MySQL的代碼可讀性比Pg差了不少，可能還要花些時日去瞭解先。
原本想寫一篇執行機制對比的文章，現在只能談談對Pg的體會，不足和錯誤之處敬請指正。
- Pg算是學院派的開源資料庫代表產品，其基於關係代數的優化、操作符的實現看起來十分親切。相較於MySQL扁平的計劃，Pg的執行計劃讓人一目瞭然。
- Pg的執行計劃靜態只讀，這是為了重用計劃方便。在具體執行某計劃時，會有一個包含只讀計劃指針 + 執行所需信息的State操作符樹（對應Plan Trees and State Trees）。類似的表達式也包括Expr和ExprState。
- Pg的執行計劃為操作符樹，連接如Merge Join，Hash Join為二元操作符；分組、排序等為一元操作符；集合運算，水平分區表相關操作，相關子查詢過濾等可能存在多個子節點。例如，每個相關子查詢生成一個SubPlan掛載到過濾條件上，如果過濾條件有n個相關子查詢那麼就會在scan下方得到n個SubPlan，這一點倒是和Oracle類似（註：12c相關查詢處理會更多地進行unnest，在子查詢中加了分組才構造出來）。
- 操作符的執行是基於狀態的，操作符之間用元組來傳遞數據。控制權由上而下，數據的傳遞由下而上。操作符對數據的處理以元組為單位，目前沒有批量的優化。
- 操作符中可能涉及表達式計算（介面ExecMakeFunctionResultNoSets），如投影、過濾。根據表達式類型如整型比較、整型相加，會有不同的ExpreState對應。ExprState包含了整型加法或比較用的函數指針，也包含有操作數。 如int_col1 + int_col2，首先載入ExprState的兩個操作數：從Tuple中的第n個欄位獲取值並存放到ExprState的參數中， 接下來使用ExprState的函數指針，結合兩個參數進行加法運算並返回結果。
總結：
Pg的執行器代碼邏輯很清晰，但是以tuple為單位的處理會使得CPU資源得不到充分利用；
表達式重用優化現在只看到了9.6引入的聚合OP重用；
