Refresh materialized views: Concurrency, transactional behaviour

Question

The official PostgreSQL 9.3 documentation on REFRESH MATERIALIZED VIEW does not yet describe it in detail.

A quote from this blog:

materialize

Answer 1

As of the release of Postgres 9.4 this isn't entirely the case. You can now refresh a materialized view concurrently using the REFRESH MATERIALIZED VIEW CONCURRENTLY command. Functionally this refreshes the view, but does so without the read lock. It is a more expensive operation in terms of computation, but if the lock is a problem for you (as it was for me, which lead me down this path), then this isn't a bad way to go.

Here's some more info from the release notes: https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.4#REFRESH_MATERIALIZED_VIEW_CONCURRENTLY

Answer 2

Take the answer with a grain of salt, since I've yet to play around with mat views, but based on this:

http://www.postgresql.org/docs/current/static/sql-creatematerializedview.html

The philosophy behind them is to treat them like smarter variations of create table as ...:

CREATE MATERIALIZED VIEW is similar to CREATE TABLE AS, except that it also remembers the query used to initialize the view, so that it can be refreshed later upon demand. A materialized view has many of the same properties as a table, but there is no support for temporary materialized views or automatic generation of OIDs.

Insofar as I read the refresh materialized view command or the docs I've found on them, they don't get updated automatically, and I understand the flow the same way you do.

The exclusive lock, I imagine, comes from the fact that you can't easily know (except in trivial cases) which rows are dirty and which aren't. Had the devs identified an efficient way of doing so, the materialized view would probably be updating automatically and concurrently.