REFRESH_MATERIALIZED_VIEW(7pg15)

💅 REFRESH_MATERIALIZED_VIEW 💅

okay bestie, so this is page 7 of the PostgreSQL 15.19 documentation and it's literally all about REFRESH_MATERIALIZED_VIEW — like, one whole manpage, and it's lowkey kind of the moment. pull up a chair 🎀

---

✨ NAME ✨

REFRESH_MATERIALIZED_VIEW — replace the contents of a materialized view 🦋

---

✨ SYNOPSIS ✨

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

that's it. that's the whole vibe. 🫶

---

✨ DESCRIPTION ✨

so REFRESH MATERIALIZED VIEW completely replaces the contents of a materialized view. no leftovers, no "hmm what was in here before" — old contents? discarded. gone. 💀

one important thing: to run this command you must be the owner of the materialized view. it's giving main character energy and you need the credentials to match. 👑

now, the two flavors:

• if WITH DATA is specified — or if you just don't say anything and it defaults to that — the backing query gets executed to provide the new data, and the materialized view is left in a scannable state. yes ma'am, fully functional, ready to be read 🌸
• if WITH NO DATA is specified, no new data is generated and the materialized view is left in an unscannable state. it's empty, it's resting, it's not giving anything 🙈

real talk: CONCURRENTLY and WITH NO DATA may not be specified together. periodt. pick one, not both.

---

✨ PARAMETERS ✨

• CONCURRENTLY — refresh the materialized view without locking out concurrent selects on the materialized view. 🎀 without this option, a refresh that affects a lot of rows will tend to use fewer resources and complete more quickly, but it could block other connections that are trying to read from the materialized view. so it's a trade-off, iykyk. this option may be faster in cases where a small number of rows are affected. this option is only allowed if there is at least one UNIQUE index on the materialized view which uses only column names and includes all rows — that is, it must not be an expression index or include a WHERE clause. so if you're out here with a fancy partial index, this flag said no ❌ this option may not be used when the materialized view is not already populated. it has to have been filled at least once, bestie. even with this option, only one REFRESH at a time may run against any one materialized view. no tag-teaming. one at a time. 💅
• name — the name (optionally schema-qualified) of the materialized view to refresh. that's your girl 🦋

---

✨ 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, right? but heads up: REFRESH MATERIALIZED VIEW does not guarantee to preserve that ordering. so don't come for her if the order shifts. 😭

---

✨ EXAMPLES ✨

this command will replace the contents of the materialized view called order_summary using the query from the materialized view's definition, and leave it in a scannable state:

REFRESH MATERIALIZED VIEW order_summary;

and this one will free storage associated with the materialized view annual_statistics_basis and leave it in an unscannable state:

REFRESH MATERIALIZED VIEW annual_statistics_basis WITH NO DATA;

see how they're different? obsessed. ✨

---

✨ COMPATIBILITY ✨

REFRESH MATERIALIZED VIEW is a PostgreSQL extension. it's not standard SQL, it's our thing. 💜

---

✨ SEE ALSO ✨

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

go read those too, the whole family ate 🔥

---

and that's the tea, bestie 🍓 this page is straight out of the PostgreSQL 15.19 docs, dated 2026 — go refresh something iconic today 👑💖