【參賽作品53】openGauss SQL執行器

正如注釋所說，該函式負責跟蹤嵌套深度，一旦深度超出限制，則拋出一個例外， 4、執行完成這部分后，進入到standard_ExecutorRun(queryDesc, direction, count);函式中呼叫了CreateExprContext函式，在EState中為運算式計算創建背景關系，

5、hook 上被掛載了函式 hypo_executorEnd_hook

它的作用是重置 isExplain 標志，此時查詢已經執行完了，所以對標志進行重置，為下一輪查詢做好作業，6、進入standard_ExecutorEnd；相關函式有：（1）ExecFreeExprContex計劃節點的ExprContext應該在執行器關閉期間被顯式釋放，因為可能有需要呼叫的關倍訓呼，(上述例程生成的其他資源，如投影資訊，不需要顯式釋放，因為它們只是每查詢記憶體背景關系中的記憶體，)然而……在ExecEndNode期間不需要這樣做，因為FreeExecutorState會釋放EState中的任何剩余的ExprContexts，讓FreeExecutorState這樣做，可以讓ExprContexts以相反的創建順序被釋放，而不是像我們在這里洗掉它們時那樣按照創建順序被釋放，這就節省了在FreeExprContext中清除串列的O(N^2)作業，

運行機制：1、Postgres行程opengauss與PostgreSQL類似，是多行程結構的資料庫，在PostgreSQL中主要有postmaster, postgres, vacuum, bgwriter, pgarch, walwriter, pgstat等行程，postmaster負責在啟動資料庫的時候創建共享記憶體 并初始化各種內部資料結構，如鎖表，資料庫緩沖區等，該行程在資料庫中只有一個，在資料庫啟動以后負責監聽用戶 請求，創建postgres行程來為用戶服務，

Postgres行程負責執行客戶端發出的所有的SQL陳述句及自定義函式，在opengauss中與Postgres行程相關的代碼在src/gusskernel/process/tcop/postgres.cpp檔案中，Postgres行程的入口函式是PostgresMain，

陳述句exec_simple_query(query_string)負責決議SQL陳述句，生成查詢計劃，執行查詢計劃，將查詢結果回傳給客戶端，我們組主要進行分析的是opengauss執行查詢計劃的程序，<o:p></o:p>

<o:p> 2、執行器的整體執行流程執行器（executor）采用優化器創建的計劃，并對其進行遞回處理以提取所需的行的集合，這本質上是一種需求驅動的流水線執行機制，即每次呼叫一個計劃節點時，它都必須再傳送一行，或者報告已完成傳送所有行，
EState：執行器在呼叫時的主要作業狀態，由ExecutorStart函式設定執行器全域狀態estate中保存了査詢涉及的范圍表(es_range_table)、Estate所在的記憶體背景關系(es_query_cxt，也是執行程序中一直保持的記憶體背景關系)、用于在節點間傳遞元組的全域元組表(es_TupleTable)和每獲取一個元組就會回收的記憶體背景關系(es_per_tuple_exprContext) ，;PlanState：PlanState是所有PlanState-type節點的虛父類執行器初始化時，ExecutorStart會根據査詢計劃樹構造執行器全域狀態(estate)以及計劃節點執行狀態(planstate)，在査詢計劃樹的執行程序中，執行器將使用planstate來記錄計劃節點執行狀態和資料，并使用全域狀態記錄中的es_tupleTable欄位在節點間傳遞結果元組，執行器的清理函式ExecutorEnd將回收執行器全域狀態和計劃節點執行狀態，狀態節點之間通過lefttree和righttree指標組織成和査詢計劃樹結構類似的狀態節點樹，同時，每個狀態節點都保存了指向其對應的計劃節點的指標(PlanState型別中的Plan欄位)，4、執行器的主要函式分析在opengauss中與執行器主要相關的代碼在src/gusskernel/runtime/executor/execMain.cpp檔案中，主要函式有 ExecutorStart ()、 ExecutorRun ()、ExecutorFinish ()、ExecutorEnd ()，初始化階段：在這個階段執行器會完成一些初始化作業，通常的做法是遍歷整個執行樹，根據每個算子的不同特征進行初始化執行，入口函式為ExecutorStart ()，這個例程必須在任何查詢計劃的開始執行時呼叫，它接受一個以前由CreateQueryDesc創建的QueryDesc(它是分開的，只是因為一些地方使用QueryDescs實用命令)，填充QueryDesc的tupDesc欄位來描述將回傳的元組，并設定內部欄位(estate和planstate)，ExecutorStart ()函式代碼如下所示：

ExecutorRun ()首先呼叫standard_ExecutorStart()完成查詢，然后ExecutorRun ()函式在之后進行SQL 自調優，即查詢執行完畢時，基于運行時資訊分析查詢計劃問題，standard_ExecutorRun()函式主要做的作業就是運行計劃，在執行程序中會呼叫ExecutePlan完成査詢計劃的執行；該函式的主體部分是一個大的回圈，每一次回圈都通過ExecProcNode函式從計劃節點狀態樹中獲取一個元組，然后對該元組進行相應的處理(增刪查改)，然后回傳處理的結果，當ExecProcNode從計劃節點狀態樹中再也取不到有效的元組時結束回圈程序，ExecProcNode的執行程序也和ExecInitNode類似：從計劃節點狀態樹的根節點獲取資料，上層節點為了能夠完成自己的處理將會遞回呼叫ExecProcNode從下層節點獲取輸入資料(一般為元組)，然后根據輸入資料進行上層節點對應的處理，最后進行選擇條件的運算和投影運算，并向更上層的節點回傳結果元組的指標，同ExecInitNode 一樣，ExecProcNode 也是一個選擇函式，它會根據要處理的節點的型別呼叫對應的處理函式，例如，對于NestLoop型別的節點，其處理函式為ExecNestLoop，ExecNestLoop函式同樣會對NestLoop型別的兩個子節點呼叫ExecProcNode以獲取輸入資料，如果其子節點還有下層節點，則以同樣的方式遞回呼叫ExecProcNode進行處理，直到到達葉子節點，每一個節點被ExecProcNode處理之后都會回傳一個結果元組，這些結果元組作為上層節點的輸入被處理形成上層節點的結果元組，最終根節點將回傳結果元組，

每當通過ExecProcNode從計劃節點狀態樹中獲得一個結果元組后，ExecutePlan函式將根據整個陳述句的操作型別呼叫相應的函式進行最后的處理，對于不掃描表的簡單查詢(例如select 1)，呼叫的是Result節點，通過ExecResult函式直接輸出“査詢”結果，對于需要掃描表的查詢(例如select xx from tablexx這種)，系統在掃描完節點后直接回傳結果，而對于增刪改查詢，情況特殊，有一個專門的ModifyTable節點來處理它：主要呼叫了ExecInsert、ExecDelete、ExecUpdate這三個函式進行處理，對于插入陳述句，則首先需要呼叫ExecConstraints對即將插入的元組進行約束檢査，如果滿足要求，ExecInsert會呼叫函式heap_insert將元組存盤到存盤系統，對于洗掉和更新，則分別由 ExecDelete 和 ExecUpdate 呼叫 heap_delete 和 heap_update 完成，清理階段：因為執行器在初始化階段向系統申請了資源，所以在這個階段要完成對資源的清理，入口函式為 ExecutorFinish ()、ExecutorEnd ()，ExecutorFinish：此例程必須在最后一次ExecutorRun呼叫之后呼叫，它執行清理操作，比如觸發AFTER觸發器，它與ExecutorEnd是分開的，因為EXPLAIN ANALYZE需要在整個運行時中包含這些操作， standard_ExecutorFinish()主要做的作業就是運行ModifyTable節點，執行佇列后觸發器，除非告訴不需要，ExecutorEnd ()：此例程必須在任何查詢計劃執行結束時呼叫，之后會呼叫standard_ExecutorEnd()函式，然后呼叫ExecEndPlan處理執行狀態樹根節點釋放已分配的資源，最后釋放執行器全域狀態EState完成整個執行程序，清理程序的任務主要是回收初始化程序中分配的資源、投影和選擇結構的記憶體、結果元組存盤空間等，計劃節點執行狀態樹清理完之后，ExecutorEnd還將呼叫FreeExecutorState清理執行器全域狀態，（4）函式呼叫關系：對Sort節點的整個查詢執行周期里的節點的函式呼叫堆疊如下：