Updating materialized view
This concurrent update is still performing a complete fresh query (not incremental).
So CONCURRENTLY does not save on the overall computation time, it just minimizes the amount of time your materialized view is unavailable for use during its update.
Materialized views have their own advantages in many scenarios: faster access to data than needs to be brought from a remote server (read a file on postgres server through file_fdw, etc.), using data that needs to be refreshed periodically (cache system), projecting data with embedded ORDER BY from a large table, running an expensive join in background periodically, etc.
I can also imagine some nice combinations with data refresh and custom background workers.
A materialized view can also be set as not scannable thanks to the clause WITH NO DATA of REFRESH.
postgres=# REFRESH MATERIALIZED VIEW aam WITH NO DATA; REFRESH MATERIALIZED VIEW postgres=# SELECT count(*) FROM aam; ERROR: materialized view "aam" has not been populated HINT: Use the REFRESH MATERIALIZED VIEW command. This makes sense as the data this view has might not reflect the current state of its parent relation(s).
The new status of table aa is effective on its materialized view aam only once REFRESH has been kicked.
Oracle supplies DBMS_SNAPSHOT and DBMS_MVIEW packages, which we can use to refresh materialized views / snapshots.Who said that automatic data refresh on a materialized view was not possible? postgres=# SELECT pg_relation_size('aa') AS tab_size, pg_relation_size('aav') AS view_size, pg_relation_size('aam') AS matview_size; tab_size | view_size | matview_size ---------- ----------- -------------- 36249600 | 0 | 18137088 (1 row) A materialized view uses storage (here 18M), as much as it needs to store the data it fetched from its parent table (with size of 36M) when running the view query.The refresh of a materialized view can be controlled really easily.At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by Kai Gai Kohei, with a decision on how best to implement sepgsql still pending. The materialized view can also be refreshed with updated data by running once again the query it uses for its projection, or have its data truncated.In the last case it is left in an non-scannable state.