[08:13:42] legoktm: hi [08:32:44] jynus: Hi. Around? [08:33:49] yes [08:34:10] I asked this earlier but it doesn't look like anyone responded. [08:34:25] https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/master/central-auth.sql#L118-L121 Is this supposed to be like this? [08:34:25] I mean, primary keys are indexed by default, right? [08:34:25] wait, the order is different [08:34:25] but still [08:34:26] is that right in general? [08:35:32] define "right", what issue do you see? [08:36:02] two different indexes for the same fields [08:36:50] assuming they are both used [08:37:13] (so they key here is the queries performed, but lets assume they are used) [08:37:18] yes, it is right [08:37:31] mysql uses btree indexes [08:37:42] b+tree for innodb in particular [08:37:53] the order of the indexes matter [08:38:04] and let me give you a diagram that tell you why [08:51:09] http://imgur.com/a/Akojv [08:51:17] Glaisher^ [08:52:37] the index order is important in some cases, specially if the second row of the index is used for a range access [08:53:19] if both queries are used with equality sign, it would be mostly redundant [08:54:46] Yeah, thanks. I know that index order is important when writing the query. I was just wondering whether it's right to have two indexes for the same fields. [08:56:16] IF the queries need it yes [08:56:33] they are 2 different indexes [08:56:59] Alright [08:57:02] Thanks again. :) [08:58:22] to clarify, PRIMARY KEY(lu_wiki, lu_name) and INDEX(lu_wiki, lu_name) would be a mistake [08:58:46] and so would be PRIMARY KEY(lu_wiki, lu_name) and INDEX(lu_wiki) [08:59:27] but not INDEX(lu_name) or INDEX(lu_name, lu_wiki) [09:00:05] however, we should try to avoid unused indexes- there is index statistics on information_sche.index_statistics on every host [09:00:17] if you see some at 0, feel free to ping me [10:38:36] mediawiki sees some connection errors from terbium to wikidatawiki and testwikidatawiki yesterday at 21:07-21:27 [16:52:26] jynus, I think hoo was seeing some errors from terbium to the dbs [16:52:45] Yes, but that was because something overloaded terbium's NIC [16:54:52] ok, I was checking for errors on db1036 after the chage I did, saw no peaks. But we will see during the weekdays. [18:10:27] jynus, can https://phabricator.wikimedia.org/T86415 just be fixed by me running the alter table or do you want to run it yourself when you have time? it's a 26k row table in wikitech's db on silver, no replication or any major traffic to worry about [18:10:51] (am trying to keep wikitech consistent with everything else while it's separate :/) [18:11:22] wikitech and 26K rows? you can do it if are confident [18:12:09] Query OK, 0 rows affected (2.51 sec) [18:12:10] :) [18:12:19] thanks [18:12:46] main issues is then there is a lot of traffic on a table [18:12:54] thanks for doing it, BTW [18:20:03] I did the index as well of course [18:29:37] I found some other inconsistencies, nothing concerning though [18:30:47] page.page_no_title_convert is missing from labswiki but that was from 2006 and never used, details (and proposal to remove from prod) in https://phabricator.wikimedia.org/T86342 [18:31:55] page.page_lang is on labswiki but not metawiki - proposal to add to prod is in https://phabricator.wikimedia.org/T69223 [18:33:54] strange [18:34:04] probably just because it's a newer install [18:34:12] if it is documented, we can work on it at other time