结论：关联大型分区表性能差主因是未触发分区剪枝或连接方式不当；postgresql 10+声明式分区需满足条件（如join/where含分区键等值或范围条件、类型一致、无复杂逻辑）才能剪枝，否则全表扫描。
直接说结论：关联大型分区表性能差，90%不是分区本身的问题，而是查询没走分区剪枝（partition pruning）或连接方式不当。PostgreSQL 10+ 的声明式分区默认支持剪枝，但必须满足条件，否则会扫描全部子表。
为什么JOIN大分区表会变慢？
常见错误现象是 EXPLAIN ANALYZE 显示执行计划里出现多个 Append 节点，且每个子分区都参与了 Nested Loop 或 Hash Join —— 这说明优化器没剪枝，实际做了全分区扫描。
- 分区键未出现在 JOIN 条件或 WHERE 中（例如用
id关联，但分区键是created_at） - 关联字段类型不一致（如一边是
timestamptz，另一边是date），导致隐式转换阻断剪枝 - 被关联的分区表是“非原生”分区（比如用触发器模拟的老式分区），PostgreSQL 无法识别其分区结构
- 使用了
OR、IN (subquery)等复杂条件，让剪枝逻辑失效
确保分区剪枝生效的关键写法
剪枝不是自动开启的魔法，它依赖查询条件与分区键的严格匹配。以下写法才能触发：
- JOIN 条件中必须包含分区键的等值比较（
=）或范围比较（BETWEEN/>= AND ），且两边类型完全一致 - 避免在分区键上套函数：错写
WHERE date_trunc('month', created_at) = '2024-01-01'；应改写为WHERE created_at >= '2024-01-01' AND created_at - 若关联两个分区表，建议它们用相同字段分区（如都按
created_at），并确保 JOIN 条件能同时约束双方 - 对时间范围查询，优先用
AND组合的闭开区间（start ），比 <code>BETWEEN更稳定兼容剪枝逻辑
JOIN策略选择：Hash Join vs Nested Loop
即使剪枝生效，JOIN 算法选错也会拖慢性能。分区表通常数据量大，Nested Loop 容易放大 I/O 压力：
- 当小表（驱动表）能被剪枝到 1–3 个分区，且内存足够容纳其全部数据时，
Hash Join效率最高 - 若驱动表剪枝后仍很大（比如跨 12 个月），而被驱动表有高效索引，可强制用
/*+ Leading(t1) UseNL(t2) */（需启用pg_hint_plan）引导Nested Loop+ 索引扫描 - 避免
Merge Join，它要求双方都排序，分区表天然无全局顺序，强制排序代价极高 -
work_mem必须设足：若 Hash Table 溢出到磁盘，性能断崖下跌；可通过EXPLAIN中的Hash Cond行查看是否出现disk: xxxkB
容易被忽略的元数据和统计问题
剪枝依赖准确的分区边界信息和行数估计，这两项常被忽视：
- 新建分区后必须立即执行
ANALYZE对该分区单独分析（ANALYZE orders_202406），否则优化器可能误判为空或数据量极大 - 父表本身不需要
ANALYZE，但若用pg_class.reltuples手动估算，注意它只反映父表元数据，不聚合子表 - 定期检查
pg_partitioned_table和pg_inherits是否一致，某些迁移工具（如pgslice）切换后若未清理旧表依赖，会导致剪枝失败 - 如果分区数量超过 100，考虑关闭
enable_partitionwise_join = off（默认 on），避免规划器陷入组合爆炸；实测在宽表多分区场景下，关掉反而更快
