Postgres分区表与非分区表关联时如何利用索引？

首先，咱们来拆解下为什么idx_statuschanges_taskid索引没被查询规划器选中：你查询的是父表partition.tasks，但实际符合t.status = 'Done'的数据只在tasks_closed分区里。PostgreSQL处理继承式分区表时，可能会因为统计信息滞后、分区数据范围不明确，或者判断全表扫描成本更低，从而跳过索引。下面是几个可行的解决方法：

1. 更新统计信息，让规划器做出正确判断 #

PostgreSQL的查询规划严重依赖表的统计信息，如果统计信息过时，规划器很可能误判索引的价值。先执行以下命令更新两张表的统计信息：

ANALYZE partition.tasks;
ANALYZE partition.statuschanges;

更新完成后重新执行你的查询，看看规划器是否会选择使用索引。

2. 直接查询目标分区，缩小数据范围 #

既然t.status = 'Done'的数据只存在于tasks_closed分区，直接查询这个分区而非父表，能让规划器更清晰地掌握关联的taskid范围，从而更倾向于使用statuschanges的索引：

SELECT t.taskid 
FROM partition.tasks_closed t
JOIN partition.statuschanges s ON s.taskid = t.taskid;

这种写法比查询父表更高效，既避免了规划器扫描所有子分区的开销，又通过明确的数据范围凸显了索引的价值。

3. 检查执行计划，判断是否真的需要索引 #

有时候规划器选择全表扫描是合理的——比如statuschanges表数据量很小，全表扫描的成本反而比索引扫描更低。你可以用EXPLAIN ANALYZE查看执行计划，确认背后的原因：

EXPLAIN ANALYZE 
SELECT t.taskid FROM partition.tasks t, partition.statuschanges s 
WHERE t.status = 'Done' AND s.taskid = t.taskid;

如果输出显示Seq Scan on statuschanges s，但表数据量确实很大，再考虑后续优化；如果表本身很小，全表扫描反而是最优选择，不用强行追求索引。

4. 临时强制使用索引（仅用于测试） #

如果你只是想验证索引是否能正常工作，可以临时关闭顺序扫描的开关（不要在生产环境长期开启）：

SET enable_seqscan = off;
-- 执行你的查询
SELECT t.taskid FROM partition.tasks t, partition.statuschanges s WHERE t.status = 'Done' AND s.taskid = t.taskid;
-- 记得改回默认设置
SET enable_seqscan = on;

这个方法仅用于确认索引的可用性，不是长期解决方案，因为强制关闭顺序扫描可能导致其他查询的性能下降。

5. 确认索引和外键的一致性 #

虽然你已经创建了索引，但要确保statuschanges.taskid的类型和tasks.taskid完全一致（都是integer，这点你已经满足），同时索引处于有效状态。可以用以下命令检查索引状态：

SELECT indexname, indisvalid FROM pg_indexes WHERE tablename = 'statuschanges' AND schemaname = 'partition';

如果indisvalid的值为true，说明索引是正常可用的。

内容的提问来源于stack exchange，提问作者Naveen Kumar Gautam