深入 PostgreSQL 内部：5 个关键阶段拆解查询处理全流程
引言当您向 PostgreSQL 发送查询时，后端会经历多个处理阶段。每个阶段承担着不同的职责，以确保您能在最短时间内获得准确响应。虽然这些阶段可能庞大而复杂，但理解它们在查询处理中的角色对 PostgreSQL 开发者至关重要。本文将概述每个查询处理阶段的功能及其在 PostgreSQL 架构中的重要性。
5 个查询处理阶段
https://img2024.cnblogs.com/blog/3599012/202504/3599012-20250408162121673-583004374.png
解析器（Parser）
PostgreSQL 的解析器使用 lex（Flex 词法分析器）和 yacc（Bison 解析器）工具创建。这些工具通过正则表达式定义文件生成对应的 C 语言源代码结构，生成的源文件位于 src/backend/parser 目录下，并在编译 PostgreSQL 时通过 make 自动生成。
简要总结：
[*]检查语法错误
[*]生成解析树（parse tree）
[*]使用 Flex 和 Bison 解析查询语法
[*]入口地址：parser/parser.c
分析器（Analyzer）
分析器负责验证解析器生成的 raw_parsetree 结构。例如：检查表名有效性、插入数据类型匹配和字段存在性，最终将对象名称转换为内部 OID（对象标识符），并生成查询树（query tree）。
简要总结：
[*]执行语义分析
[*]验证数据库对象（表、列等）
[*]将名称转换为内部 OID
[*]生成查询树
[*]入口地址：parser/analyze.c
重写器（Rewriter）
重写器(Rewriter)的主要功能是对分析器输出的查询树进行重写和优化。
例如：检查是否引用了其他 VIEW 或 RULE 结构。如果有，它将重写语句并将 VIEW 和 RULE 转换为相应的语句。它输出一个优化后的查询树供计划器模块使用。
简要总结：
[*]负责在需要时重写查询
[*]如果查询访问了 VIEW 或 RULE 对象，它将根据这些 VIEW 或 RULE 的定义进行扩展（或重写）
[*]入口地址：rewrite/rewriteHandler.c
查询规划器（Planner）
负责执行语句成本估算和生成优化的查询计划。根据语句类型、表结构、是否有索引及其大小等，计算不同的执行方法（也叫路径）。
每个路径都有一个估算成本，成本最低的路径被认为是最优查询计划。最终，生成一个最优查询计划（PlannedStmt 结构），并将其发送给执行器模块（executor）执行。
PostgreSQL 中的规划器模块相对复杂。大功能的开发通常需要对规划器有一定的理解，甚至需要对其进行修改。
get_relation_info() 调用：
plancat.c 中的 get_relation_info() 是规划器成本估算中的一个重要函数。它告诉规划器：
[*]表中有多少页
[*]数据（元组）有多少
[*]有多少索引
[*]哪一列是索引键
[*]是否有外部表
[*]其他信息
这些信息是规划器进行成本估算的基础。它通过访问方法获取这些信息：
[*]堆访问方法（Heap Access Method）— 获取数据表信息
[*]索引访问方法（Index Access Method）— 获取与索引相关的信息
简要总结：
[*]负责生成执行计划
[*]确定所有可能的获取结果的方法（或路径）
[*]选择能以最短时间完成查询的最佳方法
[*]入口地址：optimizer/plan/planner.c
执行器（Executor）
执行器的主要目的是运行由规划器生成的执行计划。它实际上由 portal 模块控制，后者是实际执行的促进者。根据执行计划的性质，可能会调用 executor 或 processUtility：
请参阅下面的插图了解 ProcessUtility 和 Executor 的职责。
https://img2024.cnblogs.com/blog/3599012/202504/3599012-20250408162200396-555512959.png
简要总结：
[*]根据执行计划执行查询
[*]访问 PostgreSQL 后端中的多个其他模块来完成查询
[*]入口地址：executor/execMain.c
执行器之后发生了什么？
执行器模块依赖于其他几个模块来完成查询。它很可能会与访问方法层（表和索引访问方法）接口，该层负责实际的数据操作（读取或写入）或表和索引数据。访问方法层又依赖于其他模块（缓冲区管理器和存储管理器）来处理实际的数据读写。
请参阅下面的图示：
查询处理生命周期
从源代码的角度来看，查询处理是通过调用 exec_simple_query() 函数开始的。除非你使用游标或扩展查询协议，否则你通过 psql 发出的绝大多数查询都是从这里开始的。
在 exec_simple_query() 中，它会调用每个查询处理阶段提供的入口函数，最终返回 DestReceiver 对象。
请参阅下面的插图：
https://img2024.cnblogs.com/blog/3599012/202504/3599012-20250408162259735-1636998058.png
Portal – DestReceiver
无论查询最终是进入 ProcessUtility 还是 Executor，它最终都会返回一个或多个结果。这些结果存储在 TupleTableSlot（简称 TTS）结构中，其中包含一个或多个元组作为结果。
元组可以理解为行数据。一个元组中可能包含多个值，分别对应相应的列。PostgreSQL 目前只支持 Heap 作为元组类型，也称为 HeapTuple。Heap 的行为定义在 HeapAccessMethod 中。
TTS 存储在 DestReceiver 结构中，它告诉 Portal 模块结果应该呈现的位置，标志着查询处理的结束。
本文由博客一文多发平台 OpenWrite 发布！
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]