Re: Materialized views WIP patch
От | Kevin Grittner |
---|---|
Тема | Re: Materialized views WIP patch |
Дата | |
Msg-id | 1361460958.27538.YahooMailNeo@web162906.mail.bf1.yahoo.com обсуждение исходный текст |
Ответ на | Re: Materialized views WIP patch (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> wrote: > I assume that at some point matviews will get (auto-)updateable, > just as normal views recently got. I'm dubious about that. Every use case I've seen for MVs involves aggregation, although they are a generalized feature, so that won't always be true. But if you have a view like: CREATE MATERIALIZED VIEW tm AS SELECT t.type, sum(t.amt) AS totamt FROM t GROUP BY t.type; ... I don't see how that can be updateable. If I add 5 to totamt for some row, what do you do? I expect that 99% of MVs will be updated asynchronously from changes to the underlying data -- what do you do if someone updates a row that no longer exists in the underlying data. This are just seems fraught with peril and out of sync with the usual uses of MVs. > What about DISABLE? DISCARD or DEALLOCATE would also be nice but > it seems hard to fit that into existing syntax. Thanks for the suggestions. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: