PostgreSQL物化视图REFRESH命令不返回耗时，需通过psql的\timing on或日志log_min_duration_statement获取；CONCURRENTLY模式含全量查询与行比对两阶段，后者隐性开销大，且pg_stat_statements统计不可靠。
REFRESH 命令本身不返回耗时，得靠日志或外部计时
REFRESH MATERIALIZED VIEW 和 REFRESH MATERIALIZED VIEW CONCURRENTLY 执行时不会输出执行时间，PostgreSQL 也不提供内置的“刷新耗时指标表”。想拿到真实耗时，只能从两个入口下手：数据库日志（需提前配置）或客户端主动计时。
最轻量的做法是在 psql 中用 \timing on 开启语句计时：
psql -U myuser -d mydb mydb=# \timing on mydb=# REFRESH MATERIALIZED VIEW CONCURRENTLY mv_orders;
它会直接在控制台打印类似 Time: 4287.342 ms 的结果——这是端到端耗时，含网络、解析、锁等待、查询执行、索引比对（CONCURRENTLY 模式下）等全部环节。
注意：\timing 只对当前 psql 会话有效，且无法捕获后台任务（如 pg_cron 调度的刷新）的耗时。
开启 log_min_duration_statement 是生产环境监控的底线配置
如果物化视图刷新是通过 pg_cron 或应用层调用的，必须依赖 PostgreSQL 日志。关键配置项是 log_min_duration_statement，设为 1000（毫秒）可记录所有超 1 秒的语句，包括 REFRESH：
- 在
postgresql.conf中添加或修改：log_min_duration_statement = 1000 - 确保
log_statement = 'ddl'或'all'（REFRESH属于 DDL 类操作） - 重启或执行
SELECT pg_reload_conf();生效
刷新执行后，日志中会出现类似条目：
2026-09-03 00:45:22.112 UTC [12345] LOG: duration: 8423.678 ms statement: REFRESH MATERIALIZED VIEW CONCURRENTLY mv_orders;
这个 duration 值就是内核实际执行耗时，不含客户端往返延迟，更可信。但要注意：日志默认不记录执行用户和数据库名，建议同时启用 log_line_prefix = '%t [%p] %u@%d ' 补全上下文。
CONCURRENTLY 刷新的“隐性耗时”常被忽略：唯一索引扫描与行比对
很多人只关注 REFRESH 语句总耗时，却没意识到 CONCURRENTLY 模式下有两阶段开销：
- 第一阶段：重新执行原始
SELECT查询，生成新结果集（和非并发模式一样） - 第二阶段：逐行比对新旧数据，依赖唯一索引定位差异，再执行
INSERT/UPDATE/DELETE同步（这部分不体现在EXPLAIN中，但占总耗时 30–70%）
这意味着即使原始查询很快，如果物化视图上 UNIQUE INDEX 未命中缓存、或存在大量变更行，第二阶段会显著拖慢整体耗时。可通过 EXPLAIN (ANALYZE, BUFFERS) 查看新查询部分的 I/O 和缓冲区使用，但无法观测比对阶段——只能靠日志 duration 值反推。
一个典型信号：当 CONCURRENTLY 耗时远高于普通 REFRESH（比如 3 倍以上），基本可以判定是比对阶段在卡住，该检查索引是否覆盖全部行、是否被其他写入阻塞、以及变更密度是否过高。
不要依赖 pg_stat_statements 统计 REFRESH 耗时
pg_stat_statements 扩展确实能统计 SQL 执行频次和平均耗时，但它对 REFRESH 语句支持有限：
- PostgreSQL 16 中，
REFRESH MATERIALIZED VIEW会被归类为UTILITY类型语句，在pg_stat_statements中可能不显示，或仅以泛化形式（如REFRESH MATERIALIZED VIEW）出现，丢失具体视图名 - 更关键的是，它统计的是“解析后执行”的耗时，不包含锁等待时间——而
REFRESH最常见的瓶颈恰恰是等待ACCESS EXCLUSIVE或SHARE UPDATE EXCLUSIVE锁
所以，线上环境若已启用 pg_stat_statements，可查，但不能信；真正要定位刷新慢，还是得靠日志 duration + pg_locks 快照 + EXPLAIN ANALYZE 三者交叉验证。
真正容易被忽略的点是：耗时统计必须区分“谁在刷”和“刷什么”。同一张物化视图，用 CONCURRENTLY 刷和不用，底层执行逻辑完全不同，不能混在一起看平均值；而不同视图之间，因数据量、索引质量、源表压力差异巨大，聚合统计反而会掩盖问题。
