PostgreSQL物化视图刷新耗时远超创建，升级v13后出现异常

针对你从v11升级到v13后遇到的问题，核心在于物化视图创建与刷新的执行逻辑在v13中存在关键差异，具体原因如下：

• 原子性刷新的额外IO开销
  PostgreSQL 13对REFRESH MATERIALIZED VIEW的原子性实现做了调整：创建物化视图时是直接将查询结果写入新的数据文件；而刷新时，默认会先把查询结果写入临时文件，再原子替换原物化视图的数据文件。这个临时文件写入+原子替换的流程，相比创建时的直接写入，多了一次数据拷贝和文件替换的IO操作——如果你的存储系统对临时文件的IO性能弱于常规数据文件，耗时会被显著放大。

• 查询计划的场景化差异
  创建物化视图时，优化器针对“一次性生成全量数据”的场景生成最优执行计划；而刷新时，优化器可能会因为物化视图已存在的元数据（如关联的索引、统计信息）选择不同的执行路径。比如v13新增的并行查询优化策略，在刷新场景下可能因为锁机制或资源竞争，反而导致效率下降。建议分别执行EXPLAIN ANALYZE（创建时的原始查询）和EXPLAIN ANALYZE（刷新时的底层查询），对比两者的执行计划差异。

• 索引与约束的重建成本
  如果物化视图上存在索引或约束，创建时是先写入全量数据再构建索引；而刷新时，v13会先重建物化视图的数据，再重新创建所有索引和约束。v13对索引构建的并行策略默认参数做了调整，可能导致索引重建的耗时增加。此外，若刷新时有并发事务访问该物化视图，v13的锁机制会更严格，可能引发等待，进一步拉长耗时。

• 统计信息的适配问题
  升级到v13后，原有的统计信息可能未被正确更新。创建物化视图时，优化器基于底层表的最新统计信息生成计划；而刷新时，若物化视图自身的统计信息过时，优化器可能做出低效的计划选择。可以尝试在刷新前执行ANALYZE命令更新底层表的统计信息，再测试刷新耗时。

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