A materialized view stores the result of a query physically. REFRESH MATERIALIZED VIEW updates this stored data to match the current data in the original tables.
REFRESH MATERIALIZED VIEW in PostgreSQL
REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] view_name;The CONCURRENTLY option allows the view to be refreshed without locking it for selects, but requires a unique index.
Without CONCURRENTLY, the view is locked during refresh, blocking reads.
sales_summary and locks it during the refresh.REFRESH MATERIALIZED VIEW sales_summary;sales_summary without locking it for selects, allowing users to query it during refresh.REFRESH MATERIALIZED VIEW CONCURRENTLY sales_summary;This example creates a materialized view that counts products by category, refreshes it to store current data, then selects all rows ordered by category.
CREATE MATERIALIZED VIEW product_counts AS SELECT category, COUNT(*) AS count FROM products GROUP BY category; REFRESH MATERIALIZED VIEW product_counts; SELECT * FROM product_counts ORDER BY category;
Refreshing a materialized view can take time depending on the data size.
Use CONCURRENTLY to avoid blocking reads, but ensure a unique index exists on the materialized view.
Materialized views do not update automatically; you must refresh them manually or via a schedule.
REFRESH MATERIALIZED VIEW updates stored query results to reflect current data.
Use CONCURRENTLY to refresh without blocking reads if supported.
Refreshing is needed after changes in underlying tables to keep data accurate.