Josh Berkus <josh(at)agliodbs(dot)com> writes:
> 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.
A patch that implements only (A) will be DOA. The reason is that the
planner can *never* "swap in a MatView" on its own authority, unless it
can prove that this does not change the semantics of the query. Which
it obviously will be unable to do unless there's a fully transparent
continuous-update scheme in place.
So the correct approach is to work on (B) first. When and if we get to
a sufficiently transparent update implementation, we can think about
changing the planner.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Rusty Conover||Date: 2010-04-13 20:38:39|
|Subject: Re: BUG #5412: Crash in production SIGSEGV, equalTupleDescs (tupdesc1=0x7f7f7f7f, tupdesc2=0x966508c4) at tupdesc.c|
|Previous:||From: Tom Lane||Date: 2010-04-13 19:36:00|
|Subject: Re: psql's \d display of unique index vs. constraint |