Hi, if I understand things correctly REFRESH MATERIALIZED VIEW locks the materialized view with an AcessExclusiveLock even if the view already contains data. I am pretty sure that will - understandably - confuse users, so I vote for at least including a note about that in the docs.
This fact imo reduces the usability of the matviews features as it stands atm considerably. I think we should be very careful not to advocate its existance much and document very clearly that its work in progress. Working incrementally is a sensible thing to do, don't get me wrong... Making the refresh work concurrently doesn't seem to be too hard if its already initialized: 1) lock relation exlusively in session mode (or only ShareUpdateExlusive?) 2) build new data into a separate relfilenode 3) switch relfilenode 4) wait till all potential users of the old relfilenode are gone (VirtualXactLock games, just as in CREATE INDEX CONCURRENTLY) 5) drop old relfilenode The only problem I see right now is that we might forget to delete the old relation if we crash during 4). Even if we WAL log it, due to checkpoints causing that action not to be replayed. But that seems to be nothing new, I think the same problem exists during normal table rewrites as well, just the other way round (i.e. we forget about the new relfilenode). Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
