REFRESH_MATERIALIZED_VIEW(7)

💖 REFRESH MATERIALIZED VIEW 💖

okay bestie, so this is page 7 of the PostgreSQL 18.6 docs, and we're talking about REFRESH MATERIALIZED VIEW — the glow-up command that swaps out everything inside a materialized view. it's giving "new year new me" but for a cached query result. periodt.

---

✨ SYNOPSIS ✨

REFRESH MATERIALIZED VIEW [ CONCURRENTLY ] name
    [ WITH [ NO ] DATA ]

---

🌸 DESCRIPTION 🌸

REFRESH MATERIALIZED VIEW completely replaces the contents of a materialized view. no leftovers, no crumbs, the old contents are just discarded. gone. bye.

to run this you need the MAINTAIN privilege on the materialized view. that's the vibe check you have to pass first, no cap.

if you say WITH DATA (or just... don't say anything, because it's the default, lowkey iconic), the backing query runs and hands you fresh new data, and the materialized view is left in a scannable state — meaning yes bestie you can read from it.

if you say WITH NO DATA, no new data gets generated at all and the view is left in an unscannable state. it's empty. it's not read-ready. it's in its flop era on purpose.

⚠️ CONCURRENTLY and WITH NO DATA may not be specified together. pick a lane, babe. they do not coexist. not a drill.

---

🎀 PARAMETERS 🎀

• CONCURRENTLY — refreshes the materialized view without locking out concurrent selects on it. so other connections can still read while you're refreshing. without this option, a refresh that touches a LOT of rows will tend to use fewer resources and finish faster — but it could block other connections trying to read from the materialized view 😭. with this option, it may actually be faster in cases where only a small number of rows are affected.

this option is only allowed if there's at least one UNIQUE index on the materialized view which uses only column names and includes all rows. translation: it must not be an expression index, and it must not include a WHERE clause. so plain columns only, every row accounted for, no exceptions 💅

this option can only be used when the materialized view is already populated. it has to exist with data first, you can't manifest from nothing.

even with this option, only one REFRESH at a time may run against any one materialized view. one at a time. that's the rule. no queue-jumping.

• name — the name of the materialized view to refresh, optionally schema-qualified. i.e. you can just say the name, or you can be extra and prefix it with the schema.

---

🦋 NOTES 🦋

if there's an ORDER BY clause in the materialized view's defining query, the original contents of the materialized view will be ordered that way — cute! — but REFRESH MATERIALIZED VIEW does not guarantee to preserve that ordering. so don't come for it when the order shifts. it never promised you that.

while REFRESH MATERIALIZED VIEW is running, the search_path is temporarily changed to pg_catalog, pg_temp. noted, bestie. it's just a temp thing. it goes back.

---

🌈 EXAMPLES 🌈

this command replaces the contents of the materialized view called order_summary, using the query from the materialized view's own definition, and leaves it in a scannable state — so it's ready to be read from immediately:

REFRESH MATERIALIZED VIEW order_summary;

and this one frees the storage associated with the materialized view annual_statistics_basis and leaves it in an unscannable state. it's empty, it's free, it's not readable, it's at peace:

REFRESH MATERIALIZED VIEW annual_statistics_basis WITH NO DATA;

---

💜 COMPATIBILITY 💜

REFRESH MATERIALIZED VIEW is a PostgreSQL extension. it's not part of the standard, it's a postgres original. iykyk.

---

👑 SEE ALSO 👑

• CREATE MATERIALIZED VIEW (CREATE_MATERIALIZED_VIEW(7))
• ALTER MATERIALIZED VIEW (ALTER_MATERIALIZED_VIEW(7))
• DROP MATERIALIZED VIEW (DROP_MATERIALIZED_VIEW(7))

---

and that's the whole page, bestie, you ate that 🫶 this was straight out of the PostgreSQL 18.6 Documentation, dated 2026. go refresh something. slay 💅✨