本文主要描述SQL中UPDATE语句的源码分析，代码为PG13.3版本。
整体流程分析以update dtea set id = 1;这条最简单的Update语句进行源码分析(dtea不是分区表，不考虑并行等，没有建立任何索引)，帮助我们理解update的大致流程。
SQL流程如下：
parser(语法解析，生成语法解析树UpdateStmt，检查是否有语法层面的错误)
analyze(语义分析， UpdateStmt转为查询树Query， 会查系统表检查有无语义方面的错误)
rewrite(规则重写, 根据规则rules重写查询树Query， 根据事先存储在系统表中的规则进行重写，没有的话不进行重写，另外加一句，视图的实现是根据规则系统实现的，也是在这里需要进行处理)
optimizer(优化器：逻辑优化、物理优化、生成执行计划， 由Query生成对应的执行计划PlannedStmt， 基于代价的优化器，由最佳路径Path生成最佳执行计划Plan)
executor(执行器，会有各种算子，依据执行计划进行处理，火山模型，一次一元组)
storage(存储引擎)。中间还有事务处理。事务处理部分的代码这里不再进行分析，免得将问题复杂化。存储引擎那部分也不进行分析，重点关注解析、优化、执行这三部分。
对应的代码：
解析部分——生成语法解析树UpdateStmt关键数据结构：UpdateStmt、RangeVar、ResTarget:
用户输入的update语句update dtea set id = 1由字符串会转为可由数据库理解的内部数据结构语法解析树UpdateStmt。执行逻辑在pg_parse_query(query_string);中，需要理解flex与bison。
gram.y中Update语法的定义：
解析部分——生成查询树Query生成了UpdateStmt后， 会经由parse_analyze语义分析，生成查询树Query，以供后续优化器生成执行计划。主要代码在src/backent/parser/analyze.c中
analyze.c : transform the raw parse tree into a query tree
具体的我们看一下transformUpdateStmt函数实现：
这里面要重点关注一下transformTargetList，会将抽象语法树中的ResTarget转为查询器的TargetEntry。
对于其内部处理可参考源码src/backend/parser中的相关处理，这里不再细述。需要重点阅读一下README，PG源码中所有的README都是非常好的资料，一定要认真读。
优化器——生成执行计划这块的内容很多，主要的逻辑是先进行逻辑优化，比如子查询、子链接、常量表达式、选择下推等等的处理，因为我们要分析的这条语句十分简单，所以逻辑优化的这部分都没有涉及到。物理优化，涉及到选择率，代价估计，索引扫描还是顺序扫描，选择那种连接方式，应用动态规划呢还是基因算法，选择nestloop-join、merge-join还是hash-join等。因为我们这个表没有建索引，更新单表也不涉及到多表连接，所以物理优化这块涉及的也不多。路径生成，生成最佳路径，再由最佳路径生成执行计划。
在路径生成这块，最基础的是对表的扫描方式，比如顺序扫描、索引扫描，再往上是连接方式，采用那种连接方式，再往上是比如排序、Limit等路径......，由底向上生成路径。我们要分析的语句很简单，没有其他处理，就顺序扫描再更新就可以了。
这里先不考虑并行执行计划。我们先看一下其执行计划结果：
下面我们分析一下其执行计划的生成流程：
核心数据结构：PlannedStmt、PlannerInfo、RelOptInfo（存储访问路径及其代价）、Path
Path：所有的路径都继承自Path，所以这个比较重要。
生成update执行路径，最终都是要生成ModifyTablePath，本例中路径生成过程：Path-->ProjectionPath-->ModifyTablePath，也就是先顺序扫描表，再修改表。后面由路径生成执行计划。
现在我们生成了最优的update路径，需要由路径生成执行计划：
最终的执行计划是ModifyTable：
执行器根据上面的执行计划，去执行。主要是各种算子的实现，其中要理解执行器的运行原理，主要是火山模型，一次一元组。我们看一下其调用过程。
关键数据结构：
核心执行算子实现：
我们看一下具体执行Update的实现
再往下就是涉及到存储引擎的部分了，我们重点看一下其对外的接口输入参数。重点是这4个参数：
relation - table to be modified (caller must hold suitable lock) （要更新的那个表）
otid - TID of old tuple to be replaced （要更新的元组ID，对应的是老的元组，更新后相当于是插入一条新元组，老元组的tid值要更新为新的tid值）
slot - newly constructed tuple data to store （新元组的值）
cid - update command ID (used for visibility test, and stored into cmax/cmin if successful) （cid值，事务相关） 执行器层面的更新算子是建立在存储引擎提供的底层table_tuple_update接口之上的。是我们编写ExecUpdate以及ExecModifyTable的基础。
事务这一块主要是要理解PG中update语句并不是原地更新元组，而是插入一条新元组。因为PG实现MVCC与Mysql，Oracle的实现方式有所不同，并不是通过undo日志实现的，相当于把undo日志记录到了原有的表中，并不是单独存放在一个地方。具体的不再细述，内容太多了，以后再分析事务部分。
好了，内容很多，分析源码的时候，涉及到的知识点以及逻辑是非常多的，我们最好每次分析只抓一个主干，不然每个都分析，最后就会比较乱。就先分析到这里吧。
总结到此这篇关于Postgres中UPDATE更新语句源码分析的文章就介绍到这了,更多相关Postgres中UPDATE源码内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
