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] >
