https://bugzilla.wikimedia.org/show_bug.cgi?id=53577
--- Comment #8 from Sean Pringle <sprin...@wikimedia.org> --- True, ct_log_id cardinality still isn't brilliant, but it's better than ts_log_id. The index is one that fluctuates cardinality estimates quite a bit between slaves, requiring periodic ANALYZE. Eg, today the enwiki slaves manage to report ct_log_id cardinality values between 21 and 290251 :-| Also, ct_log_id index covers (ct_log_id,ct_tag) which is useful. I've been trying different values for innodb_stats_sample_pages (=16 and =32) on several slaves to see if cardinality for a number of flakky indexes can be stabilized without the need for regular analysis (because of http://bugs.mysql.com/bug.php?id=33278). After our chat on IRC on Friday I applied the change_tag/subquery version to other examples of slow LogPager logged on various wikis. It is generally better overall but can still be susceptible to hitting too much cold data. I'd still really like to see consideration on: - Making log_user=N clause enforced. The examples of the query that don't filter by user id hit the most rows. - If log_user=N isn't to be used then limit exposure to the last N months of data or something or change the way it's viewed entirely. - Consideration of your suggestion to break up tag_summary into three tables, which seems like a good plan given we already denormalize for tag_summary. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
