civicrm_activity_contact join performance problems (needs index?)

On a database with ~6,000 records in civicrm_activity and ~73,000 records in civicrm_activity_contact, a basic join of activity contacts (used in the Constituent Detail report) causes the MySQL process to go to 100% CPU and never complete:

SELECT activity_civireport.id
FROM civicrm_activity activity_civireport
LEFT JOIN civicrm_activity_contact civicrm_activity_target
ON activity_civireport.id = civicrm_activity_target.activity_id
AND civicrm_activity_target.record_type_id = 3
LEFT JOIN civicrm_activity_contact civicrm_activity_assignment
ON activity_civireport.id = civicrm_activity_assignment.activity_id
AND civicrm_activity_assignment.record_type_id = 1
GROUP BY activity_civireport.id
ORDER BY activity_civireport.activity_date_time desc

The equivalent query on the same set of data in the schema from 4.3 and earlier (~67,000 civicrm_activity_target rows, with a handful of civicrm_activity_assignment rows) completes with no problem:

SELECT activity_civireport.id
FROM civicrm_activity activity_civireport
LEFT JOIN civicrm_activity_target
ON activity_civireport.id = civicrm_activity_target.activity_id
LEFT JOIN civicrm_activity_assignment
ON activity_civireport.id = civicrm_activity_assignment.activity_id
GROUP BY activity_civireport.id
ORDER BY activity_civireport.activity_date_time desc

I've tried it on different machines (a VPS with 1.5GB of RAM and a laptop with 6GB RAM) and gotten the same result. Smaller amounts of activities and assignees work okay, but this overloads MySQL in the new schema, while the old way works fine (query runs in .12 second)

These two examples don't even add the join for the source contact that's now in civicrm_activity_contact, so that extra join isn't even a factor in this comparison.

What does seem to work is adding an index for the activity and record type IDs in tandem:
KEY `activity_record_type_id` (`record_type_id`,`activity_id`)

I don't know if that's the only thing that needs to happen, but something needs to be done to handle this performance problem.