Last modified: 2010-05-15 16:03:22 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 13511 - API performance issues
API performance issues
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.13.x
All All
: Normal major (vote)
: ---
Assigned To: Roan Kattouw
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-25 22:18 UTC by Aaron Schulz
Modified: 2010-05-15 16:03 UTC (History)
1 user (show)

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


Attachments

Description Aaron Schulz 2008-03-25 22:18:05 UTC
Some queries seem to go very slow or consistently die, these needs some checks to bail of large filesorts and such with row estimates, whereas some may just need to be removed. We should look for more problem queries, but the ones I noticed are:
-Query deleted revs by namespace sorted by timestamp: this degenerates into an 8+ million row quicksort for drnamespace=0. Needs to be removed
-ucprefix: this can really slow down sometimes. A row estimate that reads of the index should be done before scanning. If there are too many, it give a nice error message and bail out. This can be done just like how checkuser does it.
Comment 1 Roan Kattouw 2008-03-26 13:45:30 UTC
(In reply to comment #0)
> -Query deleted revs by namespace sorted by timestamp: this degenerates into an
> 8+ million row quicksort for drnamespace=0. Needs to be removed
Done in r32466

> -ucprefix: this can really slow down sometimes. A row estimate that reads of
> the index should be done before scanning. If there are too many, it give a nice
> error message and bail out. This can be done just like how checkuser does it.
I discovered a filesort in the usercontribs query and killed it, which made the query so efficient it doesn't need this row limiting thing (I'll just trust Domas and Simetrical on that). I implemented generic support for such a check, though, should we ever need it.

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


Navigation
Links