Views · XB Field Notes

A materialized view stores a query's result for reuse

Mon, 26 Apr 2027 00:00:00 +0000

A materialized view stores the result of a defining query so later reads can access those stored rows. It moves computation from every read into refresh operations, which can benefit repeated reporting queries. The tradeoff is an explicit freshness boundary and another relation to maintain; neither instant reads nor automatic synchronization with the source tables is guaranteed.

Stored results have their own lifecycle

A normal view stores a query definition, while a materialized view also stores its result. PostgreSQL can index the materialized result and plan reads against it without rerunning the original joins and aggregates. Ordinary source-table inserts and updates do not automatically update that stored result. Applications must query the materialized view intentionally; creating one does not transparently rewrite every equivalent source query.

REFRESH MATERIALIZED VIEW reruns the defining query and replaces the stored contents. Standard PostgreSQL refresh is not automatic incremental maintenance: even when only a few source rows changed, the defining query still has to produce the new result. Account for refresh computation, temporary work, storage, and index maintenance when comparing the total cost with repeated direct queries.

The stored rows can still be large or poorly indexed, so materialization does not make arbitrary reads free. Choose the aggregation grain and indexes according to the report’s filters and projections. Also use an ORDER BY in the reading query when ordering matters; refresh does not promise to preserve the physical order from the defining query.

Concurrent refresh changes reader access

An ordinary refresh can block readers while replacing the materialization. CONCURRENTLY permits concurrent selects to continue accessing the existing contents during refresh, with the new contents becoming visible according to transaction and snapshot rules. It still takes locks, uses resources, and can wait for other operations. Only one refresh at a time may run against a given materialized view.

Concurrent refresh requires an already populated materialized view and at least one eligible unique index using only column names and covering all rows. A partial unique index or expression index does not satisfy that requirement. The unique index lets PostgreSQL identify result rows during refresh; it is not a declaration that the source tables themselves have become immutable or unique at the same grain.

WITH NO DATA leaves a materialized view unpopulated and unscannable. It does not mean an ordinary empty result that SELECT can read, and it does not preserve the old cached answer. Populate it with a normal refresh before requesting a concurrent one. CONCURRENTLY and WITH NO DATA cannot be combined into a shortcut around these conditions.

When it breaks

A refresh schedule alone does not bound staleness. A job can start late, take a long time, fail, or wait behind another refresh; the source snapshot also precedes completion of the work. Track successful refreshes and the source coverage that the report needs, rather than assuming that a configured interval proves current data. Failed jobs must not advance a displayed freshness marker as if new results were published.

Missing or unsuitable unique indexes can make CONCURRENTLY fail when deployment expected an uninterrupted read path. Test that path before relying on it. In PostgreSQL 18, refresh also requires the applicable MAINTAIN privilege, so the role executing the scheduled job must actually be able to refresh the relation. Successful manual execution as its owner does not establish the job role’s permissions.

Check it quickly

Save this as materialized.sql and run psql -X -v ON_ERROR_STOP=1 -f materialized.sql in a disposable PostgreSQL 18 database. The role needs permission to create the test schema. The script creates matview_demo inside a transaction and rolls it back; if that name already exists, choose an unused name rather than deleting an existing schema.

\set ON_ERROR_STOP on
BEGIN;
CREATE SCHEMA matview_demo;
SET LOCAL search_path=matview_demo,pg_catalog;
CREATE TABLE sales (region text NOT NULL,amount integer NOT NULL);
INSERT INTO sales VALUES ('east',10),('west',5);
CREATE MATERIALIZED VIEW totals AS SELECT region,sum(amount) AS total FROM sales GROUP BY region;
UPDATE sales SET amount=17 WHERE region='east';
SELECT * FROM totals ORDER BY region;
DO $$ BEGIN
 REFRESH MATERIALIZED VIEW CONCURRENTLY totals;
 RAISE EXCEPTION 'concurrent refresh accepted without unique index';
EXCEPTION WHEN object_not_in_prerequisite_state THEN
 RAISE NOTICE 'concurrent refresh requires an eligible unique index';
END $$;
CREATE UNIQUE INDEX totals_region ON totals (region);
REFRESH MATERIALIZED VIEW CONCURRENTLY totals;
SELECT * FROM totals ORDER BY region;
REFRESH MATERIALIZED VIEW totals WITH NO DATA;
DO $$ BEGIN
 PERFORM * FROM totals;
 RAISE EXCEPTION 'unpopulated view was readable';
EXCEPTION WHEN object_not_in_prerequisite_state THEN RAISE NOTICE 'unpopulated view cannot be read';
END $$;
DO $$ BEGIN
 REFRESH MATERIALIZED VIEW CONCURRENTLY totals;
 RAISE EXCEPTION 'concurrent refresh populated an unreadable view';
EXCEPTION WHEN feature_not_supported THEN RAISE NOTICE 'first population needs a normal refresh';
END $$;
REFRESH MATERIALIZED VIEW totals;
DO $$ BEGIN
 IF (SELECT total FROM totals WHERE region='east') IS DISTINCT FROM 17::bigint OR
 (SELECT count(*) FROM totals) <> 2 THEN RAISE EXCEPTION 'refresh result wrong'; END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 continued showing east total 10 after the source changed to 17. Concurrent refresh without an eligible unique index failed with the expected prerequisite error. After creating the index, refresh changed the stored east total to 17 while west remained five.

WITH NO DATA then made reading fail, and a concurrent refresh could not repopulate the unscannable view. A normal refresh restored readable results and satisfied the final assertions. This fixture verifies state transitions and prerequisites, not refresh throughput. For operational sizing, measure the actual report query and test reader behavior during a representative refresh, including the effect of transaction boundaries and failed jobs.

Sources

PostgreSQL materialized views, stored results, indexing, and refresh use cases, checked 2026-09-10.
PostgreSQL REFRESH MATERIALIZED VIEW, locking, concurrent prerequisites, privileges, and unpopulated state, checked 2026-09-10.

Materialized views freeze an expensive answer

Fri, 16 Oct 2026 00:00:00 +0000

A view is a name for a query; a materialized view is that query’s result written down as data. You trade freshness for speed, and the trade only works if you decide how stale the readers can tolerate before you build it.

That decision is what makes the mechanism interesting: the refresh is not maintenance you can forget, and the wrong way to run it takes a lock that stops everyone reading the very data you precomputed for them.

A saved answer, not a live one

A plain view is a stored query, recomputed on every read. A materialized view persists the result as a table you can index and query directly, so the join and the big range scan happen at refresh time instead of per request. On sqlite 3.53 with 200,000 sales rows across 200 regions and 400 days, the region summary as a view costs 15.286 ms per read; the same answer precomputed costs 0.039 ms. That is 390x, so the saved answer pays for itself after about 390 reads — under ten seconds at fifty reads a second.

The cost does not disappear, it moves. The precomputed table is correct only as of its last refresh, and Postgres gives you no incremental maintenance by default: REFRESH MATERIALIZED VIEW completely replaces the contents and discards the old ones, rebuilding the whole result no matter how little changed.

You choose when to refresh, and how

A full refresh is blunt, so materialize at a grain you can repair cheaply. Rebuilding the whole region summary took 16.41 ms and rewrote all 200 rows to reflect two changed source rows. Materialized at day grain instead, an incremental refresh deletes and recomputes only the affected day: 2.08 ms and 4 rows. Same answer, work proportional to the change rather than to the table.

CONCURRENTLY exists because of the lock. A plain refresh takes ACCESS EXCLUSIVE, which conflicts with every other lock mode including a bare SELECT. REFRESH MATERIALIZED VIEW CONCURRENTLY takes EXCLUSIVE, which allows concurrent reads and blocks only writes. The price is real: it requires at least one unique index on the view that uses only column names and includes all rows — not an expression index, not one with a WHERE clause — the view must already be populated, WITH NO DATA cannot be combined with it, and only one refresh at a time may run against a given view.

Staleness is a correctness decision

Adding two rows to the source made 2 of 200 regions report a different revenue: region 3 shows 1,550,199 live against 550,200 materialized. Every read still succeeded and still looked authoritative. That is the shape of the problem — the wrongness is silent, and its size is bounded only by the refresh interval multiplied by the write rate.

So name the freshness budget first and pick the cadence from it: a weekly rollup and a near-real-time dashboard need intervals an order of magnitude apart, and the second probably should not be a materialized view at all. When every read must reflect the latest committed write, a stored answer is a bug with a delay on it.

When it breaks

The first failure is the refresh that blocks its own readers. Running the rebuild inside one transaction, 4 of 5 reads failed while the lock was held for 1,530 ms — the view was unavailable for exactly as long as the rebuild took. In WAL mode that same 1,530 ms refresh blocked nothing at all (0 of 308,923 reads failed), and building into a staging table and swapping it in behind a short transaction kept the exclusive window to 2 ms with 0 of 194,123 reads failing. The blast radius is every request that touches the view, for the whole rebuild, and it grows with the size of the answer rather than the size of the change.

The second failure is the view nobody refreshes. Triple the source and an un-refreshed summary still reports 111,923,298 instead of 335,769,894 — under-reporting by 67%, with no error raised anywhere. The numbers stay plausible, which is worse than a crash: dashboards, alerts, and reports keep working, and every decision made from them uses last week’s data.

Check it quickly

Confirm the view can be refreshed concurrently, then confirm it actually was:

psql -c "\d+ mv_region_summary"
psql -c "REFRESH MATERIALIZED VIEW CONCURRENTLY mv_region_summary;"
psql -c "SELECT pid, wait_event_type, left(query,60) FROM pg_stat_activity WHERE state <> 'idle';"
psql -c "SELECT count(*), max(refreshed_at) FROM mv_refresh_log;"

\d+ must show a unique index that uses plain columns and has no WHERE clause; without it the CONCURRENTLY refresh fails immediately rather than silently degrading. While it runs, pg_stat_activity should show readers proceeding — a session parked in Lock: relation means something is holding a conflicting lock. The last query is the one that catches the silent failure: if max(refreshed_at) is older than the freshness budget you declared, you are serving stale numbers no matter how healthy they look.

Sources

PostgreSQL: CREATE MATERIALIZED VIEW, creating the stored result and indexing it, checked 2026-09-16.
PostgreSQL: REFRESH MATERIALIZED VIEW, full replacement, CONCURRENTLY and the unique-index requirement, checked 2026-09-16.
PostgreSQL: explicit locking, the table-level lock modes a refresh takes, checked 2026-09-16.