PostgreSQL 14带子分区表的EXPLAIN执行卡顿问题排查求助

1. 排查查询规划器的分区枚举过载问题 #

• 计算总分区数：230主分区×20子分区=4600个分区，查询规划器处理JOIN VALUES时可能需要枚举所有分区的组合逻辑，导致内存持续分配（对应strace的brk()调用，说明在不断扩展堆内存）。可先减少VALUES子句中的条目数（比如减到10条、1条），验证EXPLAIN是否能快速返回，确认是否是条目数×分区数的组合爆炸导致规划器卡死。
• 临时关闭enable_partitionwise_join参数：执行SET enable_partitionwise_join = off;后再跑EXPLAIN，该参数默认开启时会尝试逐分区做JOIN规划，二级分区场景下可能触发大量计算，关闭后可验证是否是该逻辑导致的异常。

2. 验证统计信息与元数据一致性 #

• 刷新全表统计信息：执行ANALYZE VERBOSE splited;，确保主表和所有子分区的统计信息最新，规划器可能因统计信息缺失/过期，在估算分区过滤逻辑时陷入大量计算或死循环。
• 检查分区元数据完整性：通过系统表确认分区层级关系是否正确：

  SELECT relname, partrelid, parentid FROM pg_partition_tree('splited');
  

  核对返回的分区数量是否符合230+4600的预期，排查是否存在循环引用或无效分区条目。

3. 排查版本特定BUG #

• 查阅PostgreSQL 14已知BUG列表，重点关注二级分区表、JOIN VALUES、查询规划器相关问题。14早期版本（如14.0-14.3）存在分区表规划器处理多分区JOIN时的内存泄漏或计算死循环问题，可升级到14分支最新小版本（如14.11+）后再测试。
• 对比单级分区表的规划逻辑：创建结构相同的单级分区测试表，执行相同的JOIN VALUES查询并查看EXPLAIN输出，对比二级分区表的规划流程差异，定位是否是二级分区层级处理逻辑导致的问题。

4. 分析规划器执行栈与内存使用 #

• 使用gdb附加到卡死的会话进程，获取调用栈信息：

  gdb -p <卡住的PID>
  (gdb) bt
  

  查看调用栈是否停留在分区处理相关函数（如partition_prune、make_partition_join_plan等），确认是否是特定函数陷入无限计算或内存分配循环。
• 监控进程内存变化：用top或pmap查看进程RSS内存增长情况，若内存持续线性增长，说明规划器处理分区组合时不断分配内存但无法释放，可能存在遍历逻辑未终止的问题。

5. 简化查询与表结构做对比测试 #

• 简化查询：去掉JOIN VALUES，改用单值条件（如WHERE id_2 = ?）执行EXPLAIN，确认是否正常；再逐步增加VALUES条目数，找到触发异常的临界点。
• 简化表结构：创建仅包含2个主分区、每个主分区下2个子分区的测试二级分区表，执行相同的JOIN VALUES查询，若小体量表正常，说明是大数量分区的组合计算导致规划器过载。

内容的提问来源于stack exchange，提问作者Aleks M