| Addshore added a comment. |
In T148988#2762644, @jcrespo wrote:I think the key here that may have been missed in our previous chat is that the normalization step is the same for all wikis.
Ok, assuming that, which can create issues in the future, but that is your decision. Why do you need the other tables? You are maintaining core tables (page) creating redundant data and extra maintenance work.
Also, if you have:
enwiktionary, Ellipsis…
dewiktionary, Ellipsis...
frwiktionary, Ellipsis......Ellipsis…, Ellipsis...
Ellipsis......, Ellipsis...
This would actually be:
enwiktionary, Ellipsis…
dewiktionary, Ellipsis...
frwiktionary, Ellipsis......
Ellipsis…, Ellipsis...
As … is the only character there that is normalized.
How do you search the page for frwiktionary, if you start with @site='enwiktionary', @title='Ellipsis…'? Please do not tell me you re going to do a range of > 800 items and then a join of that + UNION, instead of a single row fetch.
A SELECT query would never be made by the extension looking for an entry for a given site, it would always query for a list of all titles / normalized titles that match a given string.
It would also be trivial to remove the 'group' from the SELECT example (and the sites table)
I would beg you to optimize first for simple point selects, then for size. I would suggest you to create an n:n relationship with all information ready to be easily read (we do 1000x times more reads than writes). Just that UNION creates a temporary table that, even small, makes unnecessary overhead.
It could be done as 2 separate selects (avoiding the UNION)?
I may also be able to rework the query to get rid of the UNION all together with some more JOINS.
Cc: hoo, Aklapper, jcrespo, Addshore, Marostegui, Minhnv-2809, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, Darkdadaah, Mbch331, Jay8g, Krenair
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
