For this question's sake lets assume that the materialized view is with a two table join.
Refreshing this view concurrently blocks all updates/inserts.This is to ensure that when refreshing the view the data is up to date.
But why can't we allow updates/inserts when doing this,there is going to be updates anyway after doing the refresh and let the updates/inserts done during the refresh can reflect in the next time we refresh it.
What exactly is the design decision by blocking inserts/updates ? Am I missing something here ?
That's a subtle one.
It locks the materialized view its self. Not the tables it references; they are not locked against writes and may continue to be used normally.
REFRESH MATERIALIZED VIEW CONCURRENTLY allows the refresh to proceed without preventing SELECTs on the view while it is being updated, per the manual. It can also perform better when updating a small portion of a big view.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With