HashJoin DPE 实现状态

当前状态：ORCA 优化阶段崩溃

实现基于 docs/hashjoin-dpe-design.md，已完成代码编写，但运行时 ORCA 优化器在处理包含分区表的 HashJoin 查询时崩溃（postgres backend SIGFAULT）。

复现命令： sql SET pg_orca.enable_orca = on; EXPLAIN SELECT * FROM prt1 JOIN t2 ON prt1.a = t2.a;

已完成的代码改动

文件 改动内容
libgpopt/src/xforms/CXformDynamicGet2DynamicTableScan.cpp Exfp() 从 ExfpNone 改为 ExfpHigh，启用 xform
gpopt/config/CConfigParamMapping.cpp enable_dynamic_tablescan 从 false 改为 true
libgpopt/src/operators/CPhysicalHashJoin.cpp 实现 PppsRequiredForJoins() DPE 逻辑：对 outer 的 partition consumer + join 谓词 → 在 inner child 上 require EpptPropagator
gpopt/translate/CTranslatorDXLToPlStmt.cpp TranslateDXLPartSelector non-Append 分支 → 生成 PartitionSelectorCS CustomScan；TranslateDXLDynTblScan → 生成 DynamicTableScanCS CustomScan
compat/executor/dyn_scan.c / .h 两个 CustomScan 节点的完整执行逻辑（新增文件）
pg_orca.cpp _PG_init 中调用 RegisterDynScanCustomScanMethods()
CMakeLists.txt 添加 compat/executor/dyn_scan.c

临时 debug 代码（待清理）

以下文件含有 fopen("/tmp/dpe_debug.log", ...) 的 fprintf 调试代码，修复后需删除： - libgpopt/src/engine/CEngine.cpp — Optimize() / RecursiveOptimize() 入口 - libgpopt/src/search/CJobGroupImplementation.cpp — FScheduleGroupExpressions() - libgpopt/src/search/CJobGroupExpressionImplementation.cpp — ScheduleApplicableTransformations() - pg_orca.cpp — _PG_init()

已排除的问题

1. Xform 未触发 ✅ 已排除

最初怀疑 CXformDynamicGet2DynamicTableScan 被 search stage 过滤掉。通过 debug trace 证明 xform 正常触发：

op_eopid=38 candidates=3 after_impl=2 stage_size=150 after_stage=2
  • eopid=38 = CLogicalDynamicGet
  • candidates=3 表示 PxfsCandidates() 返回 3 个候选 xform
  • after_impl=2 表示经过 ∩ PxfsImplementation() 后剩 2 个（ExfDynamicGet2DynamicTableScan 和 ExfDynamicGet2AppendTableScan）
  • after_stage=2 表示 ∩ PxfsCurrentStage() 没有额外过滤

2. Search stage 过滤实现 xform ✅ 已排除

PdrgpssDefault() 创建的默认 search stage 使用 PxfsExploration()，其中包含 ~150 个 xform（包括 implementation xform），stage_size=150 证实了这一点。

3. shared_preload_libraries 导致代码未更新 ✅ 已解决

postgresql.conf 中配置了 shared_preload_libraries = 'pg_orca'，.so 在 server 启动时加载。后续 LOAD 'pg_orca' 是 no-op。必须 pg_ctl restart 才能加载新代码。

当前问题：优化阶段崩溃

现象

debug log 输出以下内容后 backend 崩溃（server closed the connection unexpectedly）：

[CEngine::Optimize] called
[FScheduleGroupExpressions] pgexpr=0x931793aa8
[FScheduleGroupExpressions] pgexpr=0x9317916b0
[FScheduleGroupExpressions] pgexpr=0x931792c38
op_eopid=38 candidates=3 after_impl=2 stage_size=150 after_stage=2   ← DynamicGet
[FScheduleGroupExpressions] pgexpr=0x9317aced0
[FScheduleGroupExpressions] pgexpr=0x931790678
op_eopid=0  candidates=1 after_impl=1 stage_size=150 after_stage=1   ← LogicalGet(t2)
[FScheduleGroupExpressions] pgexpr=0x931dae738
op_eopid=11 candidates=11 after_impl=1 stage_size=150 after_stage=1  ← InnerJoin
op_eopid=11 candidates=11 after_impl=1 stage_size=150 after_stage=1  ← InnerJoin(另一个)
op_eopid=12 candidates=6 after_impl=0 stage_size=150 after_stage=0   ← NAryJoin(正常，无实现xform)
[FScheduleGroupExpressions] pgexpr=0x931db29b0

注意：[CEngine::RecursiveOptimize] 的 trace 未出现，说明崩溃发生在 implementation 阶段完成之后、RecursiveOptimize 开始之前，即 CEngine::Implement() 的某个后续步骤中。

可能的崩溃原因

根据 ORCA 优化流程，implementation 之后的步骤是 property derivation / enforcement。崩溃最可能发生在以下位置：

假设 A：CPhysicalDynamicTableScan 的 property 方法

CPhysicalDynamicTableScan 是一个存在于 vendored ORCA 代码中的物理算子。它的 PppsDerive() 会产生 EpptConsumer，依赖上层 join 提供匹配的 EpptPropagator。可能的问题： - PppsDerive() 中引用了不存在的 partition info - 某些 property 方法（如 PcrsRequired, PosDerive）对 DynamicTableScan 有特殊处理，在单节点模式下可能触发未预期的代码路径

假设 B：CPhysicalHashJoin::PppsRequiredForJoins() 新代码

新增的 DPE propagation 逻辑可能有问题： - exprhdl.DerivePartitionInfo(0) 可能在某些 group expression 上返回 null - PexprExtractPredicatesOnPartKeys() 可能在某些谓词结构上崩溃 - pps_result->Insert() 的参数可能不正确（如 rel_mdid 的引用计数问题） - InsertAllowedConsumers() 的使用方式可能不正确

假设 C：AppendEnforcers / PartitionSelector 插入

ORCA 的 enforcer 机制在看到 inner child 需要 EpptPropagator 时，会尝试插入 CPhysicalPartitionSelector。这个过程中可能： - PartitionSelector 的构造依赖了某些在单节点模式下不存在的信息 - enforcer 和 property resolution 之间的交互导致无限递归或空指针

调试困难

  • 无 core dump：macOS 默认不生成 core dump（/cores/ 为空）
  • LLDB 不可用：因为 OBJECT library 编译方式，LLDB 报大量 “debug map object file changed” 错误，无法有效设置断点
  • 无 PG log：logging_collector 关闭，stderr 输出未被捕获

下一步排查计划

1. 获取崩溃堆栈（最优先）

方案 A — 启用 core dump： ```bash ulimit -c unlimited sudo sysctl kern.corefile=/tmp/core.%P

重启 postgres，复现崩溃，用 lldb /path/to/postgres /tmp/core.XXX 分析


方案 B — 启用 PG logging 捕获 backtrace：

postgresql.conf

logging_collector = on log_directory = ‘/tmp/pg_log’ ```

方案 C — 在关键路径添加更多 fprintf trace 缩小范围： - CEngine::Implement() 结束后 - CJobGroupOptimization 中 - CPhysicalDynamicTableScan::PppsDerive() - CPhysicalHashJoin::PppsRequiredForJoins() 各分支

2. 修复崩溃后的验证

  1. EXPLAIN 输出应显示： HashJoin -> Custom Scan (DynamicTableScanCS) on prt1 -> Hash -> Custom Scan (PartitionSelectorCS) -> Seq Scan on t2

  2. EXPLAIN ANALYZE 应显示实际只扫描了匹配的分区

  3. 不含 join 的查询（SELECT * FROM prt1 WHERE a > 10）应 fallback 到 AppendTableScan（DTS 被 property enforcement 淘汰）

3. 清理

  • 删除所有 /tmp/dpe_debug.log 相关的 fprintf 调试代码
  • 确认 NLJ DPE 路径仍然工作正常

环境信息

  • PostgreSQL data dir: /tmp/pgd3
  • Port: 15434
  • shared_preload_libraries = 'pg_orca'（需 restart 加载新代码）
  • Build: cd build && ninja -j$(nproc) && ninja install && pg_ctl -D /tmp/pgd3 restart
  • psql: /Users/jianghua/code/postgresql/src/bin/psql/psql -p 15434 -d postgres