https://bugzilla.wikimedia.org/show_bug.cgi?id=53577
--- Comment #11 from Sean Pringle <[email protected]> --- You're right, most of the slow queries we've seen in spikes do filter by log_user. But there are others that don't that also run slow. Ishmael, S3, db1003: /* IndexPager::buildQueryInfo */ select log_id, log_type, log_action, log_timestamp, log_user, log_user_text, log_namespace, log_title, log_comment, log_params, log_deleted, user_id, user_name, user_editcount, ts_tags from `logging` left join `user` on ((log_user=user_id)) left join `tag_summary` on ((ts_log_id=log_id)) where (log_type not in(?+)) and (log_type != ?) order by log_timestamp desc limit ? I went to S3 because that's where I saw the query form previously (zhwiktionary at the time). A quick check on S2 slaves doesn't show the same query running slow there, though there are other versions: * IndexPager::buildQueryInfo */ select log_id, log_type, log_action, log_timestamp, log_user, log_user_text, log_namespace, log_title, log_comment, log_params, log_deleted, user_id, user_name, user_editcount, ts_tags from `logging` left join `user` on ((log_user=user_id)) left join `tag_summary` on ((ts_log_id=log_id)) where (log_type != ?) and log_type = ? and log_namespace = ? and log_title = ? and ((log_deleted & ?) != ?) order by log_timestamp desc limit ? It's possible we'll trawl some of these up with the existing patch. Just something to keep in mind. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
