On Mon, Apr 12, 2010 at 1:50 PM, Josh Berkus <josh(at)agliodbs(dot)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
> 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
In response to
pgsql-hackers by date
|Next:||From: Josh Berkus||Date: 2010-04-12 18:18:15|
|Subject: Re: Virtual Private Database|
|Previous:||From: Josh Berkus||Date: 2010-04-12 17:50:46|
|Subject: Re: GSoC - proposal - Materialized Views in PostgreSQL|