| Anomie added a comment. |
What I got out of the meeting we just had:
Should we introduce content_sha1?
DBAs don't really care. Narrower tables are better, but the cost here probably isn't very significant if it's needed.
Making the field nullable would allow for reclaiming the majority of the space without an alter if we decide we don't need it after all (although I think the difference is only 7 or 8 bits per row versus setting it empty?).
Should we build in support for sharing (partitioning) on the page ID?
DBAs say no to MySQL's built-in partitioning. If we're going to do partitioning then we would need do it at the application level rather than the DB level.
I note this gives us more flexibility. For example, we don't actually need the page_id in the tables in order to shard by page_id as long as all the code that is doing the DB access knows the page_id to be able to use the right shard.
Should slot_revision be declared BIGINT right away?
This wasn't discussed that I recall. See the existing answer in T174028#3664170. However,
If that maintenance is going to happen anyways, we could probably go for int with slot_revision and schedule both maintenances at the same time?
Of course we can schedule the change of slot_revision at the same time we schedule the change of rev_id and every field that refers to rev_id, it's just one more ALTER. I suppose what Daniel is really looking for is for someone to say which is worse, performance impact of joining a bigint with an int or the time it'll take to alter slot_revision later. It sounds like the answer at the moment is "we don't know what the performance impact is, so we can't say".
Cc: Marostegui, cicalese, Abit, brion, Anomie, jcrespo, gerritbot, Aklapper, daniel, E1presidente, Ramsey-WMF, Jmmuguerza, SandraF_WMF, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Acer, Lewizho99, Maathavan, Susannaanas, Wikidata-bugs, PKM, Base, matthiasmullie, aude, Ricordisamoa, Fabrice_Florin, Raymond, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
