每次更新materialized view（或每5分钟）这不是一个很好的刷新物化的方式，那么使用materialized view的意义就不存在了，我给大家解释一下我根据自己的经验用自己的逻辑找到的一种方式，这样大家以后可以找到一个更优的方式，假设我们在我们的materialized view中使用了两个表，在更新或删除表时，我们必须向表（例如refresh_materialized表）中插入一条记录（也可以使用触发器），通过该记录将执行刷新materialized view
例如：

insert into refresh_materialized 
(
    refresh_status, 
    insert_date, 
    executed_date 
)
values (
    false,
    now(), 
    null 
)

因此，在我们的调度任务中，我们可以使用以下查询：

select count(*) from refresh_materialized 
where refresh_status = false

如果count(*) will be > 0，则必须刷新materialized view，否则不执行任何操作。刷新实体化视图后，必须更新此表：

update refresh_materialized 
set 
    refresh_status = true, 
    executed_date = now() 
where 
    refresh_status = false;

请尝试并发刷新实体化视图。刷新实体化视图的数据时，PostgreSQL将锁定整个表，因此无法查询该表的数据。要避免此问题，可以使用CONCURRENTLY选项。

REFRESH MATERIALIZED VIEW CONCURRENTLY view_name;

使用CONCURRENTLY选项，PostgreSQL创建示例化视图的临时更新版本，比较两个版本，并仅对差异执行INSERT和UPDATE。
您可以在更新具体化视观表时查询具体化视观表。使用CONCURRENTLY选项的其中一个需求是具体化视观表必须有UNIQUE索引。

这里是原始海报。这是一年多的历史，但这里发生了什么，我们最终如何修复它。
TLDR：

• REFRESH MATERIALIZED VIEW <query>开始比执行用于构造视图的查询花费更长的时间（~ 1秒对~ 20秒）。
  几个星期后，这个问题被问到了，查询本身的行为开始类似（需要大约20秒才能完成）。此时，EXPLAIN ANALYZE开始显示查询的性能问题。因此，我们最终优化了底层查询（最大的性能增益是用CTE替换一些JOINS）。
  在此之后，REFRESH MATERIALIZED VIEW <query>和独立查询的性能表现正常（执行时间〈1秒）。
  这里仍然存在一个未解决的问题：为什么REFRESH MATERIALIZED VIEW <query>和独立的query在某个时间点具有不同的性能？DB查询计划器是否根据是否要物化视图来选择不同的查询计划？我想如果有人知道这种情况是否可能，请发表评论。