PG中UPDATE源码分析

本文主要描述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(存储引擎)。中间还有事务处理。事务处理部分的代码这里不再进行分析，免得将问题复杂化。存储引擎那部分也不进行分析，重点关注解析、优化、执行这三部分。

对应的代码：

exec_simple_query(const char *query_string)
// ——- 解析器部分————–
–> pg_parse_query(query_string);    //生成语法解析树
–> pg_analyze_and_rewrite(parsetree, query_string,NULL, 0, NULL);   // 生成查询树Query
    –> parse_analyze(parsetree, query_string, paramTypes, numParams,queryEnv); // 语义分析
    –> pg_rewrite_query(query);    // 规则重写

// ——–优化器———-
–> pg_plan_queries()

//——– 执行器———-
–> PortalStart(portal, NULL, 0, InvalidSnapshot);
–> PortalRun(portal,FETCH_ALL,true,true,receiver,receiver,&qc);    // 执行器执行
–> PortalDrop(portal, false);