enable_partitionwise_join 是 PostgreSQL 里一个经常被忽略的优化开关。它的作用很直接：当两张表都按 Join Key 分区，并且分区边界兼容时，优化器可以把一次大 Join 拆成多组“对应分区之间的小 Join”。这通常能减少扫描范围、降低中间结果规模，也更容易触发每个分区上的局部优化。
但它不是打开就一定变快的魔法开关。它默认通常是关闭的，原因也很工程化：分区越多，规划阶段要考虑的路径越多，规划时间和内存可能上涨。它适合被有意识地打开、观察、压测，而不是无脑写进全局配置。
它到底改变了什么
假设有两张按月份分区的表：orders 和 payments，都按 created_at 或某个等价的时间键分区。如果查询是：
SELECT *
FROM orders o
JOIN payments p ON p.order_id = o.id
WHERE o.created_at >= DATE '2024-01-01'
AND o.created_at < DATE '2024-03-01';
这不一定能触发 partitionwise join，因为 Join 条件并没有使用共同的分区键。优化器需要看到两张表在 Join Key 上有可对齐的分区关系，例如两张表都按 account_id 分区，并且 Join 条件包含 o.account_id = p.account_id。
满足条件时，原本可能是：
Join orders_all_partitions with payments_all_partitions
可以变成：
Join orders_p0 with payments_p0
Join orders_p1 with payments_p1
Join orders_p2 with payments_p2
...
Append results
这就是“partitionwise”的核心：不是改变 SQL 语义，而是改变执行计划的形状。
严格条件比开关更重要
enable_partitionwise_join = on 只是允许优化器考虑这种计划。真正能不能用，还取决于表结构和查询形态。
常见必要条件包括：
- 两边都是分区表。
- 分区策略和边界兼容，例如都按同一个 key 做 range/list/hash 分区。
- Join 条件包含分区键上的等值关系。
- 数据类型、表达式、collation 等细节不能让优化器无法证明分区可对齐。
- 优化器估算后认为这种计划成本更低，才会选择它。
这也是为什么很多人打开参数后看不到变化：不是参数没生效，而是查询没有给优化器足够的结构信息。
可以这样实践：用 EXPLAIN 对比计划
下面示例可以在本地 PostgreSQL 中直接改造运行。它创建两张按 account_id 做 hash 分区的表，并对比打开和关闭 enable_partitionwise_join 后的计划形态。
运行前需要一个 PostgreSQL 终端，例如：
psql postgresql://localhost/postgres
然后执行：
DROP TABLE IF EXISTS orders CASCADE;
DROP TABLE IF EXISTS payments CASCADE;
CREATE TABLE orders (
id bigint NOT NULL,
account_id int NOT NULL,
amount numeric NOT NULL,
PRIMARY KEY (account_id, id)
) PARTITION BY HASH (account_id);
CREATE TABLE payments (
id bigint NOT NULL,
account_id int NOT NULL,
order_id bigint NOT NULL,
paid_amount numeric NOT NULL,
PRIMARY KEY (account_id, id)
) PARTITION BY HASH (account_id);
CREATE TABLE orders_p0 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE orders_p1 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE orders_p2 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE orders_p3 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 3);
CREATE TABLE payments_p0 PARTITION OF payments
FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE payments_p1 PARTITION OF payments
FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE payments_p2 PARTITION OF payments
FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE payments_p3 PARTITION OF payments
FOR VALUES WITH (MODULUS 4, REMAINDER 3);
INSERT INTO orders
SELECT gs, gs % 1000, (random() * 100)::numeric
FROM generate_series(1, 100000) AS gs;
INSERT INTO payments
SELECT gs, gs % 1000, gs, (random() * 100)::numeric
FROM generate_series(1, 100000) AS gs;
ANALYZE orders;
ANALYZE payments;
SET enable_partitionwise_join = off;
EXPLAIN
SELECT count(*)
FROM orders o
JOIN payments p
ON p.account_id = o.account_id
AND p.order_id = o.id
WHERE o.account_id BETWEEN 10 AND 200;
SET enable_partitionwise_join = on;
EXPLAIN
SELECT count(*)
FROM orders o
JOIN payments p
ON p.account_id = o.account_id
AND p.order_id = o.id
WHERE o.account_id BETWEEN 10 AND 200;
你要观察的不是某个固定节点名，而是计划是否被拆到了分区级别。开启后，计划中可能出现多个分区表之间的 Join，再由 Append 或类似节点汇总。不同 PostgreSQL 版本、统计信息和数据量会影响最终计划，因此请以 EXPLAIN (ANALYZE, BUFFERS) 在真实数据上验证。
如果只是想对单个会话或单条任务试用，不要急着改 postgresql.conf，可以用：
SET enable_partitionwise_join = on;
如果要在某个业务角色上长期启用，可以这样做：
ALTER ROLE reporting_user SET enable_partitionwise_join = on;
这比全局打开更容易控制影响面。
什么时候值得打开
它更适合这类场景：
- 大表已经做了规范分区，并且分区键就是常见 Join Key。
- 查询经常在两个或多个同构分区表之间做等值 Join。
- 单次查询执行时间明显大于规划时间，额外规划成本可以接受。
- 你有能力通过
EXPLAIN (ANALYZE, BUFFERS)比较真实收益。
它不太适合：
- 分区数量非常多，但查询本身很短小，规划时间占比高。
- 两张表分区方式不同，或者 Join 条件没有包含分区键。
- 应用里大量临时拼接 SQL，查询形态不稳定，很难评估整体影响。
- 期望用一个参数弥补错误的分区设计。
落地建议：先在查询级别证明收益
采用 enable_partitionwise_join 的顺序应该很朴素：选出慢查询，确认表分区与 Join Key 对齐，用 SET 在会话级别打开，对比 EXPLAIN (ANALYZE, BUFFERS)，再决定是否给特定角色或特定服务启用。
检查清单可以这样写：
- Join 条件里是否有分区键等值关系？
- 两边分区数量、策略、边界是否兼容？
- 开启后执行时间是否下降，而规划时间没有失控？
- 分区数增长后，计划时间是否仍可接受？
- 是否只对报表、批处理或明确受益的角色启用？
这个参数的价值在于让已经设计良好的分区模型兑现收益。它不能替代数据建模，但在分区键和查询模式一致时，能把一次笨重的大 Join 拆成优化器更容易处理的小块。