Practice the vocabulary of precomputing and storing an expensive query's result for fast reads.
0 / 5 completed
1 / 5
At standup, a dev mentions precomputing and storing the result of an expensive query as its own physical table, so a read doesn't have to recompute that expensive join every single time. What is this stored result called?
A materialized view precomputes and stores the result of an expensive query as its own physical table, so a read against it doesn't have to recompute that expensive join every single time. A standard view recomputes its underlying query fresh on every read, which can be slow for a genuinely expensive query run frequently. This precomputed, stored result is what makes reading a complex, aggregated result fast even when the underlying computation is expensive.
2 / 5
During a design review, the team wants the materialized view refreshed automatically on a schedule, rather than becoming permanently stale after it's first created. Which capability supports this?
A scheduled refresh policy automatically recomputes and updates a materialized view on a regular interval, keeping its stored result reasonably current with the underlying data it's derived from. Creating a materialized view once with no scheduled refresh leaves it permanently stale from the moment the underlying data changes. This scheduled refresh is what keeps a materialized view actually useful over time, rather than a one-time snapshot that quickly becomes outdated.
3 / 5
In a code review, a dev notices the team documents exactly how stale a materialized view's data can be, based on its refresh interval, so a consumer of that view knows what level of freshness to expect. What does this represent?
Documented staleness bounds communicate exactly how stale a materialized view's data can be, based on its refresh interval, so a consumer knows what level of freshness to actually expect before relying on it. Leaving this undocumented risks a consumer assuming the view is always perfectly current when it's actually refreshed only periodically. This documentation is essential since a materialized view trades some data freshness for read performance, and that tradeoff needs to be visible to whoever queries it.
4 / 5
An incident report shows a financial report relied on a materialized view assumed to be real-time, but it was actually refreshed only once every six hours, leading to a decision made on stale data. What practice would prevent this?
Documenting the materialized view's actual refresh interval clearly prevents a consumer from wrongly assuming it's real-time when it's actually refreshed only periodically. Leaving this undocumented risks exactly the kind of stale-data decision this incident describes. This clear documentation is what lets a team correctly decide whether a given materialized view is fresh enough for a specific, sensitive use case like a financial report.
5 / 5
During a PR review, a teammate asks why the team uses a materialized view for an expensive, frequently run query instead of just running that query fresh against a standard view every single time. What is the reasoning?
A standard view recomputes its underlying query fresh on every single read, which becomes slow once that query is genuinely expensive and run frequently. A materialized view stores the precomputed result instead, trading some data freshness, bounded by its refresh interval, for a much faster read. The tradeoff is the need to clearly document and manage that freshness gap so a consumer isn't misled about how current the data actually is.