pg_plan_advice：PostgreSQL 查询计划控制的新方案

背景介绍

PostgreSQL 的查询优化器功能强大，通常能生成优秀的执行计划。然而，经验丰富的 DBA 和开发者偶尔会遇到需要影响或稳定优化器决策的场景。来自 EnterpriseDB 的 Robert Haas 正在开发一个重要的 contrib 模块 pg_plan_advice，旨在解决这一长期存在的需求。

本文分析了 pgsql-hackers 邮件列表上自 2025 年 10 月以来持续讨论的 pg_plan_advice 线程。

pg_plan_advice 是什么？

pg_plan_advice 是一个提议中的 contrib 模块，引入了一种专门用于控制关键规划决策的"建议迷你语言"(advice mini-language)。该模块支持：

使用 EXPLAIN (PLAN_ADVICE) 从现有查询计划生成建议字符串
通过 pg_plan_advice.advice GUC 参数应用建议字符串，以复现或约束后续的规划决策

建议语言允许控制：

连接顺序：表的连接顺序
连接方法：Nested Loop、Merge Join、Hash Join
扫描类型：顺序扫描、索引扫描（可指定具体索引）
并行执行：并行执行的位置和方式
分区连接：分区表连接的处理方式

核心设计理念

Robert Haas 在 README 中强调，主要使用场景并非让用户"战胜优化器"，而是复现过去表现良好的执行计划：

"我们不需要接受用户能比优化器做出更好规划的观点。我们只需要接受用户比优化器更能分辨好计划和坏计划。这是一个很低的门槛。优化器永远不知道它生成的计划实际执行时会发生什么，但用户知道。"

这将 pg_plan_advice 定位为计划稳定性工具，而非微观管理优化器的提示系统。

技术架构

关系标识符系统

pg_plan_advice 最创新的方面之一是其关系标识符系统(Relation Identifier System)。该系统提供对查询各部分的无歧义引用，能处理复杂场景：

同一表使用不同别名的多次引用
子查询和 CTE
分区表及其分区

标识符语法使用特殊表示法如 t#2 来区分查询中表 t 的第一次和第二次出现。

使用示例

以下是 Jakub Wartak 测试中展示的系统能力：

-- 为带别名的查询生成建议
EXPLAIN (PLAN_ADVICE, COSTS OFF) 
SELECT * FROM (SELECT * FROM t1 a JOIN t2 b USING (id)) a, t2 b, t3 c 
WHERE a.id = b.id AND b.id = c.id;

-- 输出包含：
-- Generated Plan Advice:
--   JOIN_ORDER(a#2 b#2 c)
--   MERGE_JOIN_PLAIN(b#2 c)
--   SEQ_SCAN(c)
--   INDEX_SCAN(a#2 public.t1_pkey)
--   NO_GATHER(c a#2 b#2)

然后可以选择性地应用约束：

-- 强制使用特定扫描类型
SET pg_plan_advice.advice = 'SEQ_SCAN(b#2)';

-- 重新执行 EXPLAIN 查看新计划
EXPLAIN (PLAN_ADVICE, COSTS OFF) 
SELECT * FROM (SELECT * FROM t1 a JOIN t2 b USING (id)) a, t2 b, t3 c 
WHERE a.id = b.id AND b.id = c.id;

-- 输出显示：
-- Supplied Plan Advice:
--   SEQ_SCAN(b#2) /* matched */

补丁结构（v10）

实现分为五个补丁：

补丁	描述	大小
0001	存储范围表扁平化信息	7.8 KB
0002	在最终计划中存储省略节点的信息	9.8 KB
0003	存储 Append 节点合并信息	40.4 KB
0004	允许插件控制路径生成策略	56.1 KB
0005	WIP：添加 pg_plan_advice contrib 模块	399.1 KB