[00:45:30] * aude waves :) [01:00:13] sup [17:56:23] jynus: If you have a moment you might also want to look at https://phabricator.wikimedia.org/T124443 [17:56:38] I did a little schema review for them as they plan to deploy the extension soon [17:57:10] hoo, probably not a good moment today [17:57:18] we had multiple issues :-/ [17:57:47] Yeah, I'm subscribed to all puppet patches and see quite some stuff about parser caches [17:58:16] oh, no, that is a non-issue [17:58:56] I postponed that maintenance, but there is some things going on- not 100% public, so I won't mention them here [18:00:43] can you remind me what is ores? I should know, but I only have space for very few things lately [18:01:10] Revision scoring [18:01:10] just looking at your comments they seem well reasonable [18:01:16] gotcha [18:01:57] I will need to get some time to review it, if you need it- please ping me on Monday [18:02:07] otherwise I will forget [18:02:32] Not sure how urgent it is for them [18:02:42] I've not been involved with that extension until 30 minutes ago [18:02:42] independently of that, I think lately there are too many things on the main shards [18:02:48] :-) [18:02:55] well, then tell them to ping me :-) [18:03:26] is this for sX? [18:03:49] yeah [18:03:58] not sure which wikis they target, at least Wikidata [18:03:59] becacause these would be clear candidates to be on x1 [18:04:17] they join against recentchanges [18:04:21] the problem is that we have allowed some uncontrolled growth on sX [18:04:35] But might still be doable [18:04:45] one we have not prepared for, and we are runing low on disk space there [18:04:51] not a huge issue, of course [18:05:26] but adding space to all shards is more complex than doing it on separate shards [18:05:45] that is whithout looking at the schema, some general comments [18:06:29] but you know my philosophy- no PK, not table (that is a mediwiki enforced rule) [18:06:56] and as you suggested, normalization though numeric keys [18:07:39] https://github.com/wikimedia/mediawiki-extensions-ORES/blob/8a08f7f0a28030aa9f607a1ae3c037e9a521dbf8/sql/ores_model.sql No PK, -2 [18:08:00] same for the other [18:08:07] yeah... guess that's why they have the two char fields on the other table [18:08:27] no PK- duplicate rows and no online alter table [18:08:31] so that is a no-go [18:08:57] add that or tell whoever is in charge of that to ping me [18:09:06] Will add it [18:09:51] aside from that, there is not such a thing as a "good database design" without looking at the queries [18:11:37] Yeah... I just guessed what they probably want to do with the data (join it against recentchanges, show ratings for by revision id) [18:12:05] sure [18:13:06] my biggest concert with the tables (aside from the PK) is that if the wikis should work without them, maybe they should install outside of the main cluster [18:13:25] even if that means dropping the chance to do JOINS [18:13:38] I justs do not know how it is going to be used [18:13:48] and we already have special schemas to query recentchanges [18:13:48] hm [18:14:14] because the vanilla setup doesn't work for large wikis [18:14:41] I know I am very negative, just want to understand use case before giving out recommendations [18:14:45] :-) [18:16:00] you said the same "This obviously depends on what queries you plan to do." [18:16:03] :-)