(Since it is a worthwhile performance improvement imo - ok not many courses have 900 activities, that's a bit of a special case, but we have 25 courses with more than 200...)

get_all_activity_contexts($courseid);

would made the intent of the code much clearer, and move the SQL out of course/lib.php and into accesslib.php.

Revised patch attached. Gets rid of other changes, makes new function preload_course_contexts which loads (UNION ALL) course context, module contexts, and block contexts (for blocks on course page). Performance seems similar. Changed get_fast_modinfo to call this, also threw in a call at the top of course/view to save a query loading the course context.

OK to commit this for 1.9? (Or of course feel free to make more comments...)

I may have other changes later - still working on other performance issues with ridiculous number of activities - but figure best to deal with them one at a time.

I'll merge it to HEAD and tag _MERGED later today (need to get other changes committed first).

SELECT * FROM {context} WHERE path LIKE '$coursecontext->path/%'

(I think course context will already be cached, if not, query can be adjusted.)

(There is a bug about this for Eloy, but I want to go home not look up the number, sorry!)

So at the point when I wrote this, probably the unions were faster. (We do have the special index manually added on OU servers now, for obvious reasons.)

If Eloy adds support for xmldb to make the indexes, this would probably only happen in 2.0. Once that happens, yes it would be worth re-evaluating performance of the simple LIKE query against the union, on mysql and postgres - it might perform better [or just the same and with simpler code].