一条 Select 语句在 Postgresql 中的执行链路

本文只是逻辑上的概览，并没有太过深入的设计细节的描述，对应的postgresql 的代码版本是 REL_12_2

1. DML 语句入口

如何搭建 gdb 调试pg 源代码环境，可以参考：利用GDB 快速阅读 postgresql 内核源代码

启动pg 数据库：
./bin/pg_ctl -D /home/zhg/pgsql/pgsql/data -l logfile restart
启动 psql， ./bin/psql testdb testdb 是我已经创建好的数据库，且已经创建好了一个测试表
重开一个新的终端，gdb attach -p pid 参考上文链接，需要连接到 [local] idle 进程，并设置好源码目录
在psql 终端输入查询语句 select * from a; ，此时即可在 gdb 终端进行调试。

刚进入之后整个 pg 的函数栈如下，主要是利用epoll 来处理客户端的链接。

2. 执行链路

在主进程的 PostgresMain 函数中处理来自 psql 交互终端的请求（此时还没有办法确认是一个查询请求）：

gdb 不断得next执行，最终会通过 exec_simple_query(query_string) 函数进入输入命令的处理阶段。

进入之后的主要的执行步骤以及其对应的函数有如下几个：

start_xact_command 开启事务，写入事务标记，创建快照并入栈。
pg_parse_query 根据输入的命令字符串进行 SQL 词法和语法解析，主要目的是解析出DML 命令（一个输入可能有多个 DML 命令），最后以链表的形式返回解析结果。实现代码是在 src/backend/parser/gram.y 中。
接下来都是在链表内部循环执行每一个指令

利用gdb 我们能够很清晰得看到 parsetree_list 中的内容，可以看到在我们输入的 select * from a; 这个语句中，解析出来的链表长度只有1，也就是只有一个 DML 指令，同时指令的 statement 内容是 T_SelectStmt 类型。
创建快照并入栈 PushActiveSnapshot (解析+优化时需要创建快照)，在 pg_analyze_and_rewrite(): 解析器
会生成执行计划(优化器的逻辑都在里面)： pg_plan_queries ，移除快照PopActiveSnapshot。最终优化器会对 DML 语句生成执行计划。
执行器的执行逻辑部分：
CreatePortal() --> PortalDefineQuery() --> PortalStart() --> PortalSetResultFormat() --> PortalRun() --> PortalDrop()
基本链路如下图：
finish_xact_command() 提交事务，主要是 commit部分，会写wal (redo类型的一种持久化文件，因为 DML 是 select 语句，其实不需要，这里的链路主要是在 inert/update 时会写 WAL)。

3. 执行器的详细逻辑

这里着重主要介绍上文中的第六步，也就是执行器的逻辑。
执行器的入口通过 Portal 展开，主要的几个变量如下：

Portal ：表示可以执行的或者正在执行的状态信息，包括前面优化器生成的执行计划。
Estate : 保存执行器的工作状态
TupleTableSlot : 保存元组数据的数据结构。

执行器的大体逻辑包括：

CreatePortal, 创建 Portal 变量（构造 Portal 变量），作为执行计划的载体
PortalStart, 初始化DML 对应DML 语句在底层存储引擎侧的执行逻辑，比如 select * from table; 对应的 Portal 策略是 PORTAL_ONE_SELECT，其底层默认是 heap表引擎，会将heap 表引擎底层的执行查找逻辑的函数交给 Portal 变量内部的 PlanState 的一个函数指成员。
PortalRun,执行计划，底层存储引擎的数据读取会通过上一步初始化好的函数进行。
PortalDrop，执行完成，清理对应执行过程中pin主的资源，以及触发一些插件的执行逻辑。

这主要的几个入口逻辑以及后续的执行链路基本如下：

在后续我们靠近存储引擎侧的入口部分，比如在PortalStart 调用栈中，因为我们的执行计划 Plan 在 select * from table; 这个语句下的类型是 T_SeqScan

gdb能够看到，Plan 的类型

这个时候会根据 Plan 的类型来选择对应的执行函数，如下图，根据 T_SeqScan 选择了 ExecInitSeqScan。

将选择好的具体执行DML的函数赋值给 PlanState 中ExecProcNode 回调函数变量，其他的DML 语句生成的执行计划的执行类型也会根据类型初始化为各自的 ExecProcNode

4. 总结

从代码层面来看 sql 语句的执行链路，能够完整看到一条语句如何被pg 解析，经过优化器到达执行器，在执行器内部通过什么样的方式去和底层的 heap 引擎进行交互。

以上的代码执行逻辑同样适用于其他的 DML 语句（INSERT, UPDATE, DELETE等），只是底层生成执行计划时的引擎访问函数就有差异了。

当然，这个DML 语句的执行链路都是在 PG 的主逻辑中，但是 postgres 进程还会有一些非常重要的子进程：

checkpointer，写heap 表引擎的时候只是将 insert语句插入的数据，生成了可以写入的 heap tuple放在内存中的 buffer中，后续落盘会通过 checkpointer 进行落盘。（数据的ACD 特性是通过 REDO log 保证的，前面第二节主体执行链路中提到的 start_xact_command 和 finish_xact_command 中的redo 写入的逻辑）。
autovacuum 主要是用来进行 GC heap表引擎支持MVCC 引入的多版本，当然还有一些索引之类的多版本清理。
logical replication 用来做主从复制的。
walwriter 专门负责调度写前面说到的 redo log 的。
stats collector，采集pg 内部的 stats 信息。