2009/6/5 sl contrib sl.contrib@googlemail.com:
I guess it would be the same if one sorted on revision id (rather than page_latest)? Is there a proposal one could forward to make this more efficient, by somehow also indexing on revision id?
that people can have a look?
This'll probably work (albeit breaking a few things such as apfrom, as you mentioned), but due to the inefficient queries involved, it won't make it into the MediaWiki core.
Again, is there something that could be done to make it more efficient? Or perhaps one could put some less efficient code in, but with a switch to disable it on large wikis? Just to give a little background, why I think this is important: Mediawiki is an important platform for Open Educational Resources, and when considering scenarios in developing countries, bandwidth is expensive, and so mirroring is important. Of course once you mirror, you want to start up to date, so being able to get updates since a revision or a date is important. Would really like to hear your ideas on what the best way forward is!
IMO the best way forward is still to use list=recentchanges whenever possible. A list=allrevisions module, which just grabs all revisions from the revision table (paging by rev_id), could easily be written to accommodate for getting revisions older than $wgRCMaxAge , and for initial imports without history, generator=allpages&prop=revisions (gets the top revision of every page) should do.
Roan Kattouw (Catrope)