Last modified: 2013-06-18 15:56:40 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 3945 - Special:Shortpages needs index fix to run real-time
Special:Shortpages needs index fix to run real-time
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Low normal with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?t...
:
: 4058 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-13 00:02 UTC by Allen3
Modified: 2013-06-18 15:56 UTC (History)
4 users (show)

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


Attachments

Description Allen3 2005-11-13 00:02:27 UTC
The list of pages generated by Special:Shortpages is now displaying articles
that have been deleted or are redirects.

The change in behaviour began sometime after 22:30, November 12, 2005 (UTC).
Comment 1 Brion Vibber 2005-11-17 09:58:24 UTC
Shortpages has been switched to cached mode because the indexes turn out to be 
badly inefficient for it on the large wikipedias.

Adding an appropriate index for it should be possible, so it can be switched 
back.

IIRC it requires something like (page_namespace,page_is_redirect,page_len).
Comment 2 Brion Vibber 2005-11-23 19:49:15 UTC
*** Bug 4058 has been marked as a duplicate of this bug. ***
Comment 3 Jamesday 2005-11-26 02:15:21 UTC
I tested various indexes on frwiki. Without a use or force, 
the optimiser didn't pick (page_namespace, 
page_is_redirect, page_len) but did pick (page_namespace, 
page_is_redirect, page_len, page_title). So I suggest the 
latter. That made it a covering index also, so it should be 
a very fast query.

I'll leave the test indexes on frwiki for a few hours so 
you can test yourself. Please drop the indexes when done, 
or use a private IRC chat to let me know you're done with 
them and I'll do it.

I'm not worried about the index being quite big. I don't 
expect more than one or two index pages to be loaded and do 
expect that it's better to pull in those covering index 
pages than the larger number of row pages I expect to be 
needed to get the titles for the small pages - expect those 
to be unpopular, nearly random and need more like 50 page 
loads.
Comment 4 Casey Brown 2007-09-18 02:14:46 UTC
Most Specialpages like these are cached, but are shown more user-friendly than they were at the time.  WONTFIX'ing.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-18 02:22:48 UTC
Reopening.  There's still clear benefit to having as many special pages as possible real-time, if we're willing to use the indexes.  We might judge that it's not worth it to slow table modifications for the sake of two special pages, but if so, that's not your decision to make.
Comment 6 Aaron Schulz 2008-09-16 12:03:09 UTC
I'm seeing INDEX (page_len), so maybe this is doable?
Comment 7 Aaron Schulz 2008-09-16 12:06:48 UTC
Done in r40909
Comment 8 Aaron Schulz 2008-09-20 09:02:52 UTC
Reverted in r41064
Comment 9 db [inactive,noenotif] 2012-08-06 19:27:53 UTC
fixed as part of bug 26393

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


Navigation
Links