Last modified: 2011-03-13 18:04:35 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 250 - Special:Allpages index should cache in querycache or be much faster
Special:Allpages index should cache in querycache or be much faster
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.5.x
All All
: Lowest normal with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://mediawiki.mormo.org/index.php/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-29 20:19 UTC by JeLuF
Modified: 2011-03-13 18:04 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description JeLuF 2004-08-29 20:19:15 UTC
Special:Allpages uses LogPage as a cache. The new LogPage code does not provide
this functionality.
Comment 1 Brion Vibber 2004-08-30 08:25:44 UTC
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.
Comment 2 Jamesday 2004-09-11 01:48:24 UTC
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.
Comment 3 Brion Vibber 2005-03-27 02:22:06 UTC
1.4.0 released; kicking back to 1.5 blockers.
Comment 4 Brion Vibber 2005-06-08 11:33:13 UTC
Removing from 1.5 blockers.
Comment 5 Tomer Chachamu 2005-06-08 13:02:40 UTC
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?
Comment 6 Tomer Chachamu 2005-06-12 19:54:31 UTC
Will use object cache instead.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links