PostgreSQL布尔列表分区未处理分区查询远慢于已处理分区问题问询

1. 分区配置是否存在错误 #

你的分区表语法配置没有错误，但分区设计不符合当前业务场景。你选择了会被频繁更新的IsProcessed作为LIST分区的分区键，而PostgreSQL的分区表不支持行在不同分区间的原地更新，每次更新IsProcessed字段都会触发行的跨分区迁移，是后续性能问题的根源。

2. 优化方案 #

• 先修复现有碎片化问题：在业务低峰期对ToProcessVideoIds_unprocessed分区执行VACUUM FULL public."ToProcessVideoIds_unprocessed";清理死元组、整理页面碎片，如果需要不锁表操作可以使用pg_repack工具在线整理。执行完成后你会发现未处理分区的查询耗时会明显下降，执行计划里的共享缓存命中块数会和已处理分区接近。
• 调整分区设计：建议更换分区键为不会被更新的字段（比如Id做哈希分区、或者按入库时间做范围分区），如果必须保留按IsProcessed分区的逻辑，单独调优该分区的自动清理参数：将autovacuum_vacuum_scale_factor调低到0.01甚至更小，让autovacuum更频繁地触发清理，避免死元组大量累积。
• 添加索引优化查询：如果你经常需要查询未处理的Id，可以在分区表上建立("IsProcessed", "Id")的联合索引，查询时可以直接走索引返回结果，不需要扫描表数据，性能会进一步提升。
• 优化业务更新逻辑：尽量批量标记视频为已处理，减少单条更新触发的跨分区迁移次数，降低死元组产生的速度。

3. 持续更新是否导致性能差异 #

是的，这就是性能差异的直接原因。
你每次将未处理数据标记为已处理时，PostgreSQL会先在ToProcessVideoIds_unprocessed分区将原有行标记为死元组，再向ToProcessVideoIds_processed分区插入新的行。未处理分区持续产生死元组如果清理不及时，会导致数据页面出现大量空洞，顺序扫描时需要跳过大量无效的死元组才能凑够返回的50行数据，对应执行计划里你可以看到未处理分区需要扫描7265个缓存块，而已处理分区的行都是写入后不会修改的有效数据，仅需要扫描1个缓存块就能拿到50行，因此两者性能差距极大。

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