[12:27:19] <hoo>	 jynus: re https://phabricator.wikimedia.org/T116404
[12:27:26] <hoo>	 Actually the query is fast for me all the time now
[12:27:32] <jynus>	 ok
[12:27:39] <jynus>	 please comment so :-)
[12:27:49] <jynus>	 we had an issue with those servers
[12:27:56] <jynus>	 and changed configuration
[12:27:58] <hoo>	 ok
[12:28:07] <hoo>	 I'll poke some more hosts, just to be sure
[12:28:31] <hoo>	 db1018 is still having the issues
[12:28:40] <jynus>	 do not worry
[12:28:44] <jynus>	 I need to do a full review
[12:28:56] <jynus>	 the change we have done we have only applied it to s2
[12:29:11] <jynus>	 we need to make sure it is a good step
[12:29:28] <jynus>	 because it may affect some queries positivelly and some negativelly
[12:29:49] <jynus>	 but it is now on top of my backlog to investigate it further
[12:30:09] <hoo>	 db1018 is s2 :S
[12:30:19] <jynus>	 sorry, I meant s2 api
[12:30:29] <jynus>	 so db1060 and db1054, I think
[12:30:49] <hoo>	 ah ok
[12:30:52] <hoo>	 makes sense
[12:30:54] <jynus>	 you can check for local queries
[12:30:59] <jynus>	 doing
[12:31:27] <jynus>	 SET use_stat_tables = 0; on the same connection before the query
[12:31:53] <jynus>	 we need to be 100% sure that that is a good thing for all queries before applying it globally
[12:32:01] <jynus>	 so that will take time
[12:34:38] <jynus>	 (for example, I do not think that works for db1018)
[12:34:48] <hoo>	 Yeah, doesn't seem to
[12:35:15] <hoo>	 also force index for group by doesn't work, but I've never used that befor
[12:35:38] <jynus>	 that is the bad thing about query optimization- changes sometimes fix some queries and break another
[12:35:46] <jynus>	 we need better stats
[12:36:06] <jynus>	 I will roll that for more servers now to monitor that