Last modified: 2010-05-15 16:03:22 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.
(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.
