With respect to DB optimizations, I'm happy to review patches anyone might want to submit.
> I'm expecting the next scalability issue to be the user_activity > table, which accumulates lots of data (I think we have 1.2 million+ > records already) and is used for statistics views. It's structure is > sub-optimal (e.g. the 'type' field should be split into type + > additional data rather than concatenate e.g. resize with the > resolution you're resizing to), plus I think the timline view > statistics probably needs some type of periodic aggregation or get > put into a separate table. It's meant to be more of a warehouse of access stats instead of a table that is queried often. I agree that some of the queries for summary data should be done on aggregates of this information. We should probably plan a reorg for a future release. There is a way to turn off tracking info if the table is getting out of hand and analytics information is not wanted. Chris _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
