Jeff Davis <pg...@j-davis.com> writes: > The documentation says that a materialized view is basically a > create-table-as-select except that it remembers the query. Would you say > that there is a compelling use case for this alone, or is this a > building block for more sophisticated materialized view support (e.g. > eager updating) later?
The implementation of the re-LOAD'ing command makes it already worthwile. Bonus point if locking is limited to when the new content is all computer and ready, but even without that, I want to have it. ;) I'd bikeshed and prefer the UPDATE MATERIALIZED VIEW nsp.foo; of course. The alternative is creating a view, a matching table and a stored procedure that will implement the rebuilding, for each mat view you want to have. So that's already a big step forward in my eyes. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
