Right now, update_materialized_view results in a DROP MATERIALIZED VIEW followed by a CREATE MATERIALIZED VIEW with the new version; if the view is large, this can result in substantial downtime, since the drop acquires an ACCESS EXCLUSIVE lock on the view and prevents any queries from running.

Another option would be to do CREATE MATERIALIZED VIEW {name}_tmp ; ALTER MATERIALIZED VIEW {name} RENAME TO {name}_old ; ALTER MATERIALIZED VIEW {name}_new RENAME TO {name} ; DROP MATERIALIZED VIEW {name}_old. This results in negligible downtime, but costs twice the disk space. A further improvement could be to optionally run the (potentially expensive, disk-blocking) DROP in a different transaction if you pass an argument like 'i_will_clean_up_myself: true`, but in my experimentation, just doing it this way takes some expensive matview migrations from minutes of downtime to fractions of a second.

I've attached a PR for this behavior.