Comment 2 for bug 844877

It is not *very* slow, it just seems to be at bit slower than it should be.
From reading the query plan the reason seems to be that two temp b-trees are created, which is *slow*

sele order from deta
---- ------------- ---- ----
1 0 0 SCAN TABLE event USING INDEX event_subj_id (~125000 rows)
0 0 1 SCAN SUBQUERY 1 (~100 rows)
0 1 0 SEARCH TABLE event USING INDEX event_subj_id (subj_id=?) (~2 rows)
0 0 0 USE TEMP B-TREE FOR GROUP BY
0 0 0 USE TEMP B-TREE FOR ORDER BY

It seems like all other queries are also using this temp b-trees (at least the ones I tried)
Right now I don't see a way to optimize it.