Marostegui added a comment.
In T230862#5538510 <https://phabricator.wikimedia.org/T230862#5538510>, @Anomie wrote: > Using tags has the advantage of more directly identifying the relevant revisions, //if// the planner decides that gathering all revisions with the tag then filtering by which are in RC (and probably filesorting) is a better plan than taking rows from RC (in order) and filtering by which have the tag. The equivalent querying the slots table is much less likely to be workable since it would have to fetch all revisions with the slot rather than all revisions actually changing the slot. On the other hand, I'm skeptical that long-term there would be few enough revisions so tagged that the tag-first plan would actually be better. > If the planner is going with an RC-first plan, then it seems unlikely to matter much whether it filters by joining `change_tag` or joining `slots`. There's no always-good option here, and the maybe-bad parts are the same for both. > Personally I'd lean against adding lots of rows to `change_tag`, which will be visible in various UIs, if the only use case is filtering on slots edited. Using a wider index (bigint+bigint+smallint rather than big <https://phabricator.wikimedia.org/T63111>int+int) for a filtering-join seems less troublesome than adding more to an already-tall table. But you might want to ask the DBAs for their opinion. I agree with Brad. Once this is finally release, we do have to keep a close eye on the optimizer for the first iterations, as I am worried that it will decide to use the wrong index/plan we we can end up scanning LOTS of rows. The good thing is that we can test this on 10.1 and on 10.3. TASK DETAIL https://phabricator.wikimedia.org/T230862 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Cparle, Marostegui Cc: Marostegui, EBernhardson, Cparle, dcausse, Anomie, daniel, Aklapper, Lydia_Pintscher, Tgr, Ramsey-WMF, Addshore, Tpt, Lucas_Werkmeister_WMDE, Smalyshev, Hook696, Daryl-TTMG, RomaAmorRoma, 0010318400, E.S.A-Sheild, darthmon_wmde, WDoranWMF, Meekrab2012, joker88john, DannyS712, CucyNoiD, Nandana, NebulousIris, JKSTNK, Gaboe420, Versusxo, Majesticalreaper22, Amorymeltzer, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Af420, E1presidente, Darkminds3113, Anooprao, SandraF_WMF, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, Tramullas, Acer, merbst, LawExplorer, Sethakill, Salgo60, WSH1906, Lewizho99, Maathavan, Silverfish, dg711, Poyekhali, _jensen, rosalieper, Taiwania_Justo, Jonas, Xmlizer, Susannaanas, Ixocactus, Wong128hk, Jane023, jkroll, Wikidata-bugs, Jdouglas, Base, matthiasmullie, aude, Tobias1984, El_Grafo, Dinoguy1000, Manybubbles, jayvdb, Ricordisamoa, Wesalius, Fabrice_Florin, Raymond, Jdforrester-WMF, Steinsplitter, Mbch331, Keegan, Legoktm
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
