How you redefined your project definitely makes your goal much easier to 
reach. 

As I see it,  most of what you need to do is related to figuring out how 
to create disk-cached VIEWs and how to invalidate the cache whenever any 
of the VIEW's underlying data has changed. This does not necessarily mean 
that you need to invalidate the cache for ANY change on a base table 
(though, that would also be a valid approach and much simpler to do) but 
rather only if one of the rows cached by the VIEW had changed. You will 
probably be able to extend the existing VIEW management code in the 5.0 
branch to achieve your project goal.

So... which of the many storage engines are you hoping to extend? It would 
be nice if you could do them all but I think we all anticipate that InnoDB 
will pose special challenges.

Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine


Andrew Roth <[EMAIL PROTECTED]> wrote on 10/19/2005 11:06:33 AM:

> Thanks for the clarification and comments.  I should reiterate that
> for our project, we do *not* need to actually implement materialized
> views, but only suggest refactoring and/or new components required to
> implement them.  I think implementing it would too time consuming for
> a group of three students in one term, but we can definitely post our
> findings here.  We may also have some interesting MySQL source
> architecture visualizations to show.
> 
> To make things a bit simpler, we've decided not to consider the query
> optimizer or scheduling updates.  Instead, we'll focus on the storage
> engine and adding the keyword.
> 
> My understanding of materialized views for the purposes of our
> assignment is that it's a view that caches the data when queried.  If
> the data changes, the cache will have to be recomputed (or at least
> invalidated).
> 
> -Andrew
> 
> On 10/19/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Just like Jigal, I also had to lookup the term "materialized view". 
For the
> > sake of others on the list trying to follow along: a materialized view 
is
> > basically a self-updating snapshot of a table (or tables) usually 
containing
> > some sort of intermediate statistical computations involving GROUP BY.
> >
> > For instance, if you have the raw log of visitors to your web 
sitestored in
> > your database and you frequently ran queries that created summarations 
by
> > day, you could save yourself a lot of processing time by periodically
> > precomputing a "daily table" from your raw logs showing various 
statistics
> > broken down for each date. Well, a materialized view would be one way 
to
> > implement that "daily table".
> 
> -- 
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]
> 

Reply via email to