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.

Refresh also temporarily sets search_path to pg_catalog, pg_temp. A defining query that calls a function using unqualified dynamic SQL can therefore fail even when an interactive call worked. Review name resolution inside those functions, not just the saved view query. This fixture uses direct table references and does not validate function-dependent refreshes or a scheduler’s permissions.

Unpopulated is not a readable empty answer. Historical single-transaction adapted SQL tests state gates; concurrent-reader continuity and scheduler permissions remain untested.

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;

Retained PostgreSQL 18.6 standalone SQL logs show east=10 after its source became 17. This review did not rerun it; the earlier adaptation omitted the psql directive and added command-delimiting blank lines. Client invocation and concurrent readers remain untested. 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 asserted east=17 and two rows; compare earlier displayed totals manually. 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-10-15.
PostgreSQL REFRESH MATERIALIZED VIEW, locking, concurrent prerequisites, privileges, and unpopulated state, checked 2026-10-15.

Materialized answers need freshness and cost budgets

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

A materialized answer saves repeated computation by storing a query result. The decision is economic and semantic: how much work will reuse avoid, and which source state may readers accept? This article focuses on that budget. PostgreSQL’s native materialized-view lifecycle has additional prerequisites; a stored answer should never acquire a freshness promise merely because its reads are fast.

Compare the work you actually avoid

A normal view stores a query definition. Reading a materialized result can avoid rerunning its joins and aggregates, although the saved relation still needs its own access path. Refresh moves work elsewhere rather than eliminating it. Include computation, temporary space, index maintenance, scheduling, and unsuccessful refresh attempts when estimating the cost of repeated reuse.

Break-even is refresh cost divided by the saving per read, not the ratio between direct and cached read latency. With illustrative costs of 16.41 milliseconds per refresh, 15.286 per direct read, and 0.039 per saved read, two reads repay one refresh. Those numbers are inputs to arithmetic here, not measured results. A different query, cache state, or refresh frequency changes the answer completely.

Choose an aggregation grain deliberately. Daily summaries may support repairing selected days, but late arrivals, corrections, deletes, and changes to grouping keys must identify every affected partition. PostgreSQL’s standard REFRESH MATERIALIZED VIEW still reruns the defining query; a manually maintained summary table needs its own correct incremental-maintenance protocol. Calling a table materialized does not supply that protocol.

Publish the answer and its evidence together

A successful refresh completion time is not necessarily the source time represented by the answer. A long-running query can read an earlier snapshot; upstream ingestion can itself lag. Record the source coverage or generation that matters to the report as well as job success. If a refresh fails, its success marker must not advance while old rows remain published.

A schedule does not enforce a maximum age. Delayed starts, lock waits, failed jobs, and lengthy computation all add uncertainty. Nor is numeric error bounded by write rate times elapsed time without assumptions about each change’s magnitude. One large correction can move a sum substantially. Decide whether stale reads remain useful, should carry an age indicator, or must be rejected.

When it breaks

Native PostgreSQL refresh without CONCURRENTLY acquires ACCESS EXCLUSIVE and can block readers. Concurrent refresh allows ordinary SELECT but still takes locks and requires a populated view plus an eligible all-row unique index using plain columns. EXCLUSIVE is not simply a writes-only lock: its conflicts include ROW SHARE as a general table-lock rule. Only one refresh can run on the same view at once.

SQLite transaction and WAL observations cannot establish those PostgreSQL lock rules. A fast staging-table swap is also not a universal replacement for native refresh: dependencies, privileges, object identity, and transaction boundaries need explicit handling. Keep each engine’s evidence attached to that engine, and test representative readers separately from checking the saved values.

The exact SQLite model tests one-connection failure atomicity and illustrative arithmetic. It does not establish independent-reader behavior, PostgreSQL locks or measured performance.

Check it quickly

Save this as materialized_budget.py and run Python 3. This standard-library exercise uses an SQLite in-memory table as an explicitly maintained summary. SQLite does not provide PostgreSQL’s native materialized-view commands. Keep Python assertions enabled. The exact bilingual payload passed this review on Python 3.12.14 with SQLite 3.53.1. Its single connection checks stale results, transactional publication and a failed refresh, with no reader-concurrency or performance claim.

import sqlite3

# SQLite has no native materialized-view command: this is an explicit cache table.
db = sqlite3.connect(":memory:", isolation_level=None)
db.executescript("""
CREATE TABLE sales (region TEXT NOT NULL, amount INTEGER NOT NULL);
CREATE TABLE source_version (generation INTEGER NOT NULL);
INSERT INTO source_version VALUES (1);
INSERT INTO sales VALUES ('east',10),('east',20),('west',5);
CREATE VIEW live_totals AS SELECT region,sum(amount) total FROM sales GROUP BY region;
CREATE TABLE saved_totals (region TEXT PRIMARY KEY,total INTEGER NOT NULL);
CREATE TABLE refresh_state (generation INTEGER NOT NULL);
INSERT INTO refresh_state VALUES (0);
""")

def refresh(fail=False):
 db.execute("BEGIN")
 try:
 generation = db.execute("SELECT generation FROM source_version").fetchone()[0]
 db.execute("DELETE FROM saved_totals")
 if fail:
 raise RuntimeError("injected failure after deleting old rows")
 db.execute("INSERT INTO saved_totals SELECT * FROM live_totals")
 db.execute("UPDATE refresh_state SET generation=?", (generation,))
 db.execute("COMMIT")
 except Exception:
 db.execute("ROLLBACK")
 raise

def rows(relation):
 assert relation in {"saved_totals", "live_totals"}
 return db.execute("SELECT * FROM " + relation + " ORDER BY region").fetchall()

refresh()
assert rows("saved_totals") == [("east",30),("west",5)]
db.executescript("""BEGIN;
UPDATE sales SET amount=17 WHERE region='east' AND amount=10;
UPDATE source_version SET generation=2;
COMMIT;""")
assert rows("live_totals") == [("east",37),("west",5)]
assert rows("saved_totals") == [("east",30),("west",5)]
try:
 refresh(fail=True)
except RuntimeError:
 pass
else:
 raise AssertionError("injected refresh should fail")
assert rows("saved_totals") == [("east",30),("west",5)]
assert db.execute("SELECT generation FROM refresh_state").fetchone()[0] == 1
refresh()
assert rows("saved_totals") == rows("live_totals")
assert db.execute("SELECT generation FROM refresh_state").fetchone()[0] == 2
# Illustrative costs, not timings measured by this program.
refresh_ms, direct_ms, cached_ms = 16.41, 15.286, 0.039
assert refresh_ms + 2 * cached_ms < 2 * direct_ms
assert refresh_ms + cached_ms > direct_ms
print("old answer survived failed refresh; successful refresh published generation 2")
print("illustrative break-even: 2 reads, not the direct/cached speed ratio")
print("SQLite", sqlite3.sqlite_version)
db.close()

Initially east totals thirty and west five. Updating one source amount makes the live east total thirty-seven while the saved answer remains thirty. The synthetic source generation also advances. It is a fixture-controlled marker, not a general solution for tracking arbitrary upstream changes.

The injected failure occurs after deleting saved rows inside a transaction. Rollback preserves both the old answer and generation one. The successful retry publishes updated rows and generation two together. These assertions establish the chosen failure boundary without inventing throughput measurements or claiming a cross-database locking test.

In production, ensure the refresh role can perform its work, measure the actual query, and test what readers see during success and failure. Keep an independently meaningful freshness signal with the result. Reuse is valuable when the saved work exceeds the maintenance cost and the recorded source coverage satisfies the reader’s contract.

Sources

PostgreSQL materialized views, stored results and indexing, checked 2026-10-15.
PostgreSQL refresh, complete recomputation and concurrent prerequisites, checked 2026-10-15.
PostgreSQL explicit locking, refresh lock modes and conflicts, checked 2026-10-15.
SQLite transactions, explicit commit and rollback for the scoped fixture, checked 2026-10-15.