2010/4/9 Greg Smith <g...@2ndquadrant.com>: > The main hidden complexity in this particular project relates to handling > view refreshes. The non-obvious problem is that when the view updates, you > need something like a SQL MERGE to really handle that in a robust way that > doesn't conflict with concurrent access to queries against the materialized > view. And work on MERGE support is itself blocked behind the fact that > PostgreSQL doesn't have a good way to lock access to a key value that > doesn't exist yet--what other databases call key range locking. See the > notes for "Add SQL-standard MERGE/REPLACE/UPSERT command" at > http://wiki.postgresql.org/wiki/Todo for more information. > > You can work around that to build a prototype by grabbing a full table lock > on the materialized view when updating it, but that's not a production > quality solution. Solving that little detail is actually more work than the
Hmm... I am not sure you're right about this. It's not obvious to me that a brief full-table lock wouldn't be acceptable for an initial implementation. Obviously it wouldn't be suitable for every use case but since we're talking about manually refreshed views that was bound to be true anyway. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
