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