PostgreSQL 28.6亿行大表count条件查询耗时12分钟原因咨询

从提供的执行计划可以直接定位核心问题：索引仅扫描触发了超量的堆表回查，关键指标为执行计划中的Heap Fetches: 1303955010，也就是查询过程中累计回查原表13亿次，这是12分钟耗时的核心来源。
具体原因拆解：

• PostgreSQL的MVCC机制决定了索引本身不存储行的事务可见性信息，索引仅扫描的生效前提是表的可见性映射（VM, Visibility Map） 是最新的，能直接判断索引对应的行对当前事务可见，不需要回查原表。如果表的可见性映射没有及时更新，每一行都要回查堆表判断可见性，13亿次随机IO直接把耗时拉满。
• type字段基数极低，只有两个可选值，本次查询匹配到的vendor类型行总量超过13亿，就算没有堆回查，扫描这么大范围的索引本身也会产生不小的顺序IO开销。
• 通常可见性映射失效的原因是表近期有大量写入、更新、删除操作，且没有及时执行VACUUM操作更新VM文件。

• 优先执行VACUUM ANALYZE companies;更新表的可见性映射和统计信息，执行完成后再重试查询，Heap Fetches数值会大幅下降，索引仅扫描的性能会得到指数级提升。
• 如果经常需要执行这类按type统计行数的查询，建议建立物化视图定期刷新计数值，或者用触发器实时维护customer和vendor两类数据的计数，避免每次查询都扫描全量索引。
• 可以适当调大max_parallel_workers_per_gather参数，给这类大表扫描任务分配更多并行worker进程，进一步缩短扫描耗时。

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