Patch looks OK, but from looking at it I think the DB query in the API module is less efficient than the one in getAverageRating(). I'll run an EXPLAIN on it later to see how bad it is.

Runing explain on a test mediawiki db that has almost no data in it, i get (hopefully i got this query right):

mysql> describe SELECT SUM(rfh_total)/SUM(rfh_count) as avg, SUM(rfh_count) as count, rfh_tag, rfh_page_id from reader_feedback_history where rfh_page_id = 1 and rfh_date > 200 GROUP BY rfh_page_id, rfh_tag\G

• 1. row ******* id: 1 select_type: SIMPLE table: reader_feedback_history type: ref

possible_keys: PRIMARY

    key: PRIMARY
key_len: 4
    ref: const
   rows: 6
  Extra: Using where

1 row in set (0.00 sec)

(Not sure if thats useful or not). As far as i can tell, with exception to the group by clause (in order to make it one query instead of 4), the query is the same as the one in getAverageRating

I'm mostly worried about the case where $pageids contains multiple page IDs and the WHERE clause will look like WHERE rfh_page_id IN (1,2,3) AND rfh_date > 200

That case definitly would happen - api.php?action=query&generator=allpages&prop=rating&gaplimit=max would have 500 items in $pageids.

Note, the specific use case on wikinews that i want this feature for would only deal with one article at a time. If the patch was re-written as a api.php?action=Readerfeedback&title=foo with title only being allowed to have a single page, would that be more acceptable efficiency wise?

(In reply to comment #4)

That case definitly would happen -
api.php?action=query&generator=allpages&prop=rating&gaplimit=max would have 500
items in $pageids.

Note, the specific use case on wikinews that i want this feature for would only
deal with one article at a time. If the patch was re-written as a
api.php?action=Readerfeedback&title=foo with title only being allowed to have a
single page, would that be more acceptable efficiency wise?

Absolutely.

This extension is obsoleted by ArticleFeedback.