Wikimedia Bugzilla is closed!

I've removed the code that causes it to fail, but of course now it's not caching
at all. That was always a hack and an ugly one, so I'm glad to see it gone.
(People routinely came across that and other cached pages and tried to edit or
delete it, or complained that the page was corrupted. Sigh...)

The index list for Allpages should either be made much much faster, or its index
points saved into the querycache table. Changed summary to reflect this.

It can be made much faster, assuming that the Apache users 
are able to create a temporary table - and they should, 
because it's likely to be a good optimisation in many 
situations.

Select all appropriate titles from cur into temporary table 
with an indexed autoincrementing numeric field. You can now 
select records with values 1,50; 51,100 or whatever using 
that indexed numeric field. Very fast and takes just one pass 
through cur. Finessing required for final elements.

Quite a few of the slow reports could probably use this 
temporary table - uncategorised pages is another which could, 
if cur_id was also present in the copy. Using this temporary 
table approach, allpages would be a fairly low load 
operation. Generating it once an hour seems like a useful 
approach. All of the slow jobs could set a flag somewhere to 
indicate the time it was last generated and update it only 
when required.

The current code causes other queries to back up/ accumulate 
because it runs for so long each time it gets a pair of 
values. And it does that about 1,000 times for en for just 
the main index page.

1.4.0 released; kicking back to 1.5 blockers.

Removing from 1.5 blockers.

Special:Allpages code:

http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/includes/SpecialAllpages.php

As I understand it, the bug is simply the slow performance of the Allpages
*index*. That is indeed slow, although subpages are pretty fast.

The key code is on lines 142-159 as of revision 1.46. If 50 rows need to be
displayed, it is making 49 queries. I'm marking this as depending on 764 because
I'm assuming Jamesday's suggestion of temporary tables is overall the best way
to do this. Has caching changed much since comment #2?

Will use object cache instead.