openGauss 数据库源码解析系列文章——执行器解析（1.1）

一、执行器整体架构及代码概览

本节整体介绍执行器的架构和代码。

1.1 执行器整体结构

在 SQL 引擎将用户的查询解析优化成可执行的计划之后，数据库进入查询执行阶段。执行器基于执行计划对相关数据进行提取、运算、更新、删除等操作，以达到用户查询想要实现的目的。

openGauss 在行计算引擎的基础上，增加了编译执行引擎和向量化执行引擎，执行器模块架构如图 1-1 所示。openGauss 的执行器采用的是火山模型（volcano model），这是一种经典的流式迭代模型（pipeline iterator model），目前主流的关系型数据库大多采用这种执行模型。

图 1 执行器模块架构

执行器包括四个主要的子模块：Portal、ProcessUtility、executor 和特定功能子模块。首先在 Portal 模块中根据优化器的解析结果，选择相应的处理策略和处理模块（ProcessUtility 和 executor）。其中 executor 主要处理用户的增删改查等 DML（Data Manipulation Language，数据操作语言）操作。然后 ProcessUtility 处理增删改查之外的其他各种情况，例如各类 DDL（data definition language，数据定义语言）

1.2 火山模型

执行器（executor）的输入是优化器产生的计划树(plan tree)，计划树经过执行器转换成执行状态树。执行状态树的每一个节点对应一个独立算子，每个算子都完成一项单一功能，所有算子组合起来，实现了用户的查询目标。在火山模型中，多个算子组成了一个由一个根节点、多个叶子节点和多个中间节点组成的查询树。

每个算子有统一的接口（迭代器模式），从下层的一个或者多个算子获得输入，然后将运算结果返回给上层算子。整个查询执行过程主要是两个流，驱动流和数据流。

驱动流是指上层算子驱动下层算子执行的过程，这是一个从上至下、由根节点到叶节点的过程，如图 7-2 中的向下的箭头所示。从代码层面来看，即上层算子会根据需要调用下层算子的函数接口，去获取下层算子的输入。驱动流是从跟节点逐层传递到叶子节点。

数据流是指下层算子将数据返回给上层算子的过程，这是一个从下至上，从叶节点到跟节点的过程，如图 1-2 中的向上的箭头所示。在 openGauss 中，所有的叶子节点都是都是表数据扫描算子，这些节点是所有计算的数据源头。数据从叶子节点，通过逐层计算，然后从根节点返回给用户。

图 2 执行器控制流和数据流示意图

1.3 代码概览

执行器在项目中的源代码路径为：src/gausskernel/runtime。下面是执行器的源码目录。

1） 执行器源码目录

执行器源码目录如表 1-1 所示。

表 1-1 执行器源码目录

2） 执行器源码文件

执行器源码目录为：src/gausskernel/runtime/模块名。文件如表 1-2 所示。

表 1-2 执行器源码文件