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.

bugzilla_wikipedia_org.to.jamesd wrote:

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.

the.r3m0t wrote:

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?

the.r3m0t wrote:

Will use object cache instead.