PostgreSQL查询执行流程从SQL解析开始，经词法语法分析生成AST，再通过重写系统处理视图与规则，形成Query Tree；随后优化器基于成本模型生成最优执行计划；执行器按计划树以迭代器模式逐层处理元组；最终结果返回客户端并释放资源。
PostgreSQL 的查询执行流程是一套完整的、模块化的处理机制，从客户端发送 SQL 语句开始，到最终返回结果集结束。整个过程涉及多个组件协同工作，包括词法/语法分析、重写、规划、优化和执行等阶段。下面详细拆解 PostgreSQL 查询的完整执行链路。
1. 查询解析（Parsing）
当一条 SQL 语句（如 SELECT * FROM users WHERE id = 1;）被发送到 PostgreSQL 服务器后，首先进入解析阶段。
该阶段由以下两个子步骤组成：
- 词法分析（Lexing）：将输入的 SQL 字符串分解成一个个“记号”（tokens），例如 SELECT、FROM、标识符 users 等。
- 语法分析（Parsing）：根据 PostgreSQL 的语法规则，将 tokens 组织成一棵抽象语法树（Abstract Syntax Tree, AST），也称为 Raw Parse Tree。这棵树结构化地表达了 SQL 的逻辑结构。
如果 SQL 存在语法错误，此阶段会直接报错并终止流程。
2. 查询重写（Rewriting）
解析生成的 AST 会被送入重写系统（Query Rewrite System），主要处理视图、规则（RULES）和一些预定义的转换逻辑。
典型场景包括：
- 用户查询一个视图时，PostgreSQL 会将视图定义中的 SELECT 语句“展开”到原始查询中。
- 系统内置的 INSERT/UPDATE/DELETE 规则可能触发额外操作（如日志记录）。
- 某些策略（如行级安全策略）也会在此阶段注入条件。
重写后的结果仍是一棵查询树，但已更接近可执行的形式，称为 Query Tree。
3. 查询规划与优化（Planning & Optimization）
这是整个流程中最复杂的部分，由查询优化器（Planner/Optimizer）完成，目标是生成高效执行路径。
输入是重写后的 Query Tree，输出是一个执行计划（Plan Tree）。
主要步骤包括：
- 生成候选路径：考虑多种访问方式，如顺序扫描、索引扫描、位图扫描、嵌套循环、哈希连接、归并连接等。
- 成本估算：基于统计信息（red">pg_statistic）、表大小、索引选择性等，估算每种路径的 CPU、I/O 成本。
- 选择最优计划：选取成本最低的执行路径，形成最终的执行计划。
你可以使用 EXPLAIN 命令查看生成的执行计划，例如：
EXPLAIN SELECT * FROM users WHERE age > 30;
若启用了 GEQO（遗传查询优化器），对于多表连接等复杂查询，PostgreSQL 可能采用启发式搜索来降低规划时间。
4. 执行引擎（Execution）
执行器（Executor）按照优化器生成的计划树逐步执行，从底层访问数据并向上层返回结果。
执行过程的核心特点：
- 以节点（Node）为单位推进，每个节点对应一种操作（如 SeqScan、IndexScan、HashJoin 等）。
- 采用迭代器模型（Volcano Model）：每个节点实现 ExecProcNode() 接口，支持 Init → GetNext → End 模式。
- 从最内层节点获取元组（tuple），逐层向上处理（过滤、投影、连接、排序等）。
- 结果通过 tuplestore 逐步返回给客户端，支持流式输出。
执行期间会访问共享缓冲区（Shared Buffer）、WAL、锁管理器等组件，确保事务一致性和并发控制。
5. 结果返回与清理
当执行器完成所有节点处理后，结果集通过通信协议（如 Frontend/Backend Protocol）发送回客户端。
随后释放相关资源：
- 清除执行上下文（EState）。
- 释放临时内存（MemoryContext）。
- 提交或回滚事务（取决于是否显式 BEGIN/COMMIT）。
若启用了 PreparedStatement 或 Portal 机制（如通过 DECLARE CURSOR），部分执行状态可能被保留用于后续 FETCH。
基本上就这些。PostgreSQL 的查询链路设计清晰、层次分明，各阶段职责明确，既保证了灵活性，又支持深度优化。理解这条链路有助于写出更高效的 SQL，也能更好解读执行计划和性能瓶颈。
