深入 PostgreSQL 内部：5 个关键阶段拆解查询处理全流程

引言

当您向 PostgreSQL 发送查询时，后端会经历多个处理阶段。每个阶段承担着不同的职责，以确保您能在最短时间内获得准确响应。虽然这些阶段可能庞大而复杂，但理解它们在查询处理中的角色对 PostgreSQL 开发者至关重要。本文将概述每个查询处理阶段的功能及其在 PostgreSQL 架构中的重要性。
5 个查询处理阶段

解析器（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 的职责。

简要总结：

• 根据执行计划执行查询
  
• 访问 PostgreSQL 后端中的多个其他模块来完成查询
  
• 入口地址：executor/execMain.c
  

执行器之后发生了什么？

执行器模块依赖于其他几个模块来完成查询。它很可能会与访问方法层（表和索引访问方法）接口，该层负责实际的数据操作（读取或写入）或表和索引数据。访问方法层又依赖于其他模块（缓冲区管理器和存储管理器）来处理实际的数据读写。
请参阅下面的图示：

查询处理生命周期

从源代码的角度来看，查询处理是通过调用 exec_simple_query() 函数开始的。除非你使用游标或扩展查询协议，否则你通过 psql 发出的绝大多数查询都是从这里开始的。
在 exec_simple_query() 中，它会调用每个查询处理阶段提供的入口函数，最终返回 DestReceiver 对象。
请参阅下面的插图：

Portal – DestReceiver

无论查询最终是进入 ProcessUtility 还是 Executor，它最终都会返回一个或多个结果。这些结果存储在 TupleTableSlot（简称 TTS）结构中，其中包含一个或多个元组作为结果。
元组可以理解为行数据。一个元组中可能包含多个值，分别对应相应的列。PostgreSQL 目前只支持 Heap 作为元组类型，也称为 HeapTuple。Heap 的行为定义在 HeapAccessMethod 中。
TTS 存储在 DestReceiver 结构中，它告诉 Portal 模块结果应该呈现的位置，标志着查询处理的结束。

本文由博客一文多发平台 OpenWrite 发布！

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

感谢发布原创作品，程序园因你更精彩

喜欢鼓捣这些软件，现在用得少，谢谢分享！

过来提前占个楼

懂技术并乐意极积无私分享的人越来越少。珍惜

懂技术并乐意极积无私分享的人越来越少。珍惜

过来提前占个楼

这个好，看起来很实用

谢谢分享，试用一下

感谢分享

感谢分享，下载保存了，貌似很强大

分享、互助 让互联网精神温暖你我

收藏一下   不知道什么时候能用到

鼓励转贴优秀软件安全工具和文档！

感谢，下载保存了

yyds。多谢分享

收藏一下   不知道什么时候能用到

新版吗？好像是停更了吧。

这个有用。

感谢分享