Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I'm not really sure what Josh was talking about in that answer. In >> terms of doing this automatically, I doubt that's likely to happen >> until we have a way to automatically update a materialized view when >> the underlying data changes --- and Kevin Grittner has done a bunch of >> work towards that, but more is needed to get us there. > > Even with auto maintenance, it seems unlikely that matviews would ever > be so transparent that it would be okay for the planner to automatically > substitute them into a query. The data in a matview is going to be at > least a little bit stale, else You're Doing It Wrong.
There are people who want all sorts of different timings for applying the changes to the matviews -- from so eager that the matview changes are immediately visible to the transaction modifying the underlying table (i.e., the same timing as a non-deferred trigger), to applying the delta "on demand" on some schedule. For that reason I think you're Doing It Wrong if there is not a decoupling of the delta calculation from the application. I think we should support all of the requested timings, but that there may be ways to take advantage of cases where the matview is always in sync with the underlying tables. My intention has been to keep those separate, but to implement one of the eager timings first, because it avoids implementing the queue and scheduling in the same patch. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
