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
