Consider a materialized view mv_customers that was refreshed 1 hour ago. If you run REFRESH MATERIALIZED VIEW CONCURRENTLY mv_customers; now, what is the expected behavior?

medium📝 query result Q5 of 15

PostgreSQL - Views and Materialized Views

Consider a materialized view mv_customers that was refreshed 1 hour ago. If you run REFRESH MATERIALIZED VIEW CONCURRENTLY mv_customers; now, what is the expected behavior?

AThe view will be refreshed but all selects will be blocked until completion

BThe view will be refreshed without locking out selects during the refresh

CThe command will fail because concurrent refresh is not supported

DThe materialized view will be dropped and recreated

Step-by-Step Solution

Solution:

Step 1: Understand CONCURRENTLY option
REFRESH MATERIALIZED VIEW CONCURRENTLY allows refresh without blocking selects.
Step 2: Effect on selects during refresh
Select queries can continue while the refresh happens in the background.
Final Answer:
The view will be refreshed without locking out selects during the refresh -> Option B
Quick Check:
Concurrent refresh = no select lock [OK]

Quick Trick: Use CONCURRENTLY to avoid blocking selects during refresh [OK]

Common Mistakes:

Assuming concurrent refresh is unsupported
Thinking selects are blocked during concurrent refresh
Confusing drop and recreate with refresh

Master "Views and Materialized Views" in PostgreSQL

9 interactive learning modes - each teaches the same concept differently

Learn Why Deep Visual Try Challenge Project Recall Time

Want More Practice?

15+ quiz questions · All difficulty levels · Free

Free Signup - Practice All Questions

Consider a materialized view mv_customers that was refreshed 1 hour ago. If you run REFRESH MATERIALIZED VIEW CONCURRENTLY mv_customers; now, what is the expected behavior?

Step 1: Understand CONCURRENTLY option

Step 2: Effect on selects during refresh

Final Answer:

Quick Check:

Want More Practice?