Andres, > 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.
+1 for mentioning it in the docs. We could stand to document what locklevels various commands take more in general. > 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... -1 from me. Postgres is currently full of fairly innocent-looking commands which take an unexpected ACCESS EXCLUSIVE lock. For example, DROP CONSTRAINT takes an accessexclusive lock, but it hasn't stopped people from using constraints, and isn't particularly high up on our todo list to fix it. This limitation is in no way crippling for this feature, or even a major detraction. I still intend to promote the heck out of this feature. Now, I agree that having a REFRESH ... CONCURRENTLY would be a wonderful feature for 9.4. But the fact that we don't have it yet is not a big deal, and I would put several other matview-related features ahead of concurrent in priority. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
