SubPlan天生排斥并行，因其作为嵌套在主扫描循环中的“回调函数”，依赖leader进程逐行驱动，worker无法共享outer tuple上下文、不支持数据分片、且执行逻辑随outer值动态变化；腾讯云通过内核改造支持SubPlan并行，需开启tencentdb_enable_subplan_parallel并满足单表聚合、等值关联、有索引等条件。
因为原生 PostgreSQL 的执行器把相关子查询编译成 SubPlan，而 SubPlan 在 14 版本前不支持并行化——它必须由 leader 进程逐行驱动，无法分发给 worker 进程并行执行。
SubPlan 为什么天生排斥并行
相关子查询（比如 SELECT id, (SELECT COUNT(*) FROM log WHERE log.user_id = u.id) FROM users u）在优化阶段会被标记为 SubPlan 节点。这个节点不是独立可调度的子任务，而是嵌套在主扫描循环里的“回调函数”：每扫到 users 表的一行，就现场调用一次子查询逻辑。worker 进程没有上下文绑定外部行的能力，也无法共享 outer tuple 的生命周期管理。
- SubPlan 不具备数据分片能力——它不操作连续页范围，而是依赖当前 outer tuple 值做随机点查或小范围过滤
- PostgreSQL 的并行模型要求所有 worker 执行**相同逻辑、不同数据段**；SubPlan 的每次执行逻辑都可能因 outer 值不同而跳转到不同索引位置或触发不同条件分支
- 共享内存中无法安全传递和同步大量 outer tuple 状态，尤其涉及多层嵌套或 volatile 函数时
腾讯云数据库怎么突破这个限制
腾讯云 PostgreSQL 在内核层改造了 SubPlan 的执行路径，核心是把部分形态的相关子查询“重写+下推”，使其能被 Gather 节点包裹，并允许 worker 携带 outer 值副本并发执行。前提是开启参数 tencentdb_enable_subplan_parallel，且子查询满足以下条件：
- 子查询是单表聚合（如
MAX()、COUNT()），不含窗口函数或DISTINCT - 关联条件为等值匹配（
=），且字段有索引支撑（否则下推后仍要全扫） - 外层扫描本身已启用并行（如并行顺序扫描），且
max_parallel_workers_per_gather > 1
例如：原生计划是 Subquery Scan on u → Seq Scan on users + SubPlan 1；开启后可能变为 Gather → Parallel Seq Scan on users + Parallel Aggregate on log（通过 hash join 或 broadcast 关联）。
你自己能做什么来绕过限制
不依赖云厂商补丁时，最有效的方式是手动重写为 JOIN + 窗口函数或 LATERAL，让优化器有机会生成可并行的物理算子：
- 把
(SELECT MAX(b.val) FROM b WHERE b.a_id = a.id)改成LATERAL (SELECT MAX(val) FROM b WHERE b.a_id = a.id) AS l—— PostgreSQL 9.3+ 支持，LATERAL 可参与并行计划生成（但需注意enable_hashjoin = on和统计信息准确） - 对高频使用的相关聚合，提前物化为
MATERIALIZED VIEW并定期刷新，避免运行时计算 - 确认
min_parallel_table_scan_size和parallel_setup_cost没被设得过高，否则即使重写后优化器也会放弃并行
真正容易被忽略的是：哪怕开了所有并行参数，只要子查询里出现 random()、now()、current_user 这类 volatile 函数，PostgreSQL 就会强制降级为 SubPlan —— 因为无法保证 worker 间结果一致。
