On Mon, Apr 12, 2010 at 1:50 PM, Josh Berkus <j...@agliodbs.com> wrote: > On 4/9/10 1:36 PM, pavelbaros wrote: >> 2) change rewriter >> - usually, view is relation with defined rule and when rewriting, rule >> is fired and relation (view) is replaced by definition of view. If >> relation do not have rule, planner and executor behave to it as physical >> table (relation). In case of materialized view we want to rewrite select >> statement only in case when we refreshing MV. In other cases rewriter >> should skip rewriting and pick up physical relation. Exclude situation >> when other rewrite rules which are not related to MV definition are >> specified. > > This was done (although not completed) against PostgreSQL 7.1 by > students in Georgia, USA, I believe. It might be worthwhile looking at > their work if I can find it (if nowhere else, it should be in the ACM). > > There are basically 2 major parts for materialized views: > > A) Planner: Getting the query planner to swap in the MatView for part of > a query automatically for query plan portions which the MatView supports; > > B) Maintenance: maintaining the MatView data according to the programmed > scheme (synch, asynch, periodic). > > I do not believe it is possible to do both of the above in one summer. > Of the two, (A) would be more useful since it is possible to manually > implement (B) using triggers, queues and cron jobs today.
I don't believe that it's possible to do EITHER of those things in one summer. I believe that a basic implementation that has NO bells and whistles at all, as originally proposed, is going to be a Very Hard Project. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
