Special:Allpages index should cache in querycache or be much faster
Closed, DeclinedPublic

Description

Author: jeluf

Description:
Special:Allpages uses LogPage as a cache. The new LogPage code does not provide
this functionality.


Version: 1.5.x
Severity: normal
URL: http://mediawiki.mormo.org/index.php/Special:Allpages

bzimport added a project: MediaWiki-Special-pages.Via ConduitNov 21 2014, 6:47 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz250.
bzimport created this task.Via LegacyAug 29 2004, 8:19 PM
brion added a comment.Via ConduitAug 30 2004, 8:25 AM

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.

bzimport added a comment.Via ConduitSep 11 2004, 1:48 AM

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.

brion added a comment.Via ConduitMar 27 2005, 2:22 AM

1.4.0 released; kicking back to 1.5 blockers.

brion added a comment.Via ConduitJun 8 2005, 11:33 AM

Removing from 1.5 blockers.

bzimport added a comment.Via ConduitJun 8 2005, 1:02 PM

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?

bzimport added a comment.Via ConduitJun 12 2005, 7:54 PM

the.r3m0t wrote:

Will use object cache instead.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.