Split translations table into per-language tables

So i was thinking about further performance tuning and I came to a conclusion (and I was thinking about this for a long time) that queries like following are never going to perform well:

SELECT DISTINCT s.sid, s.value, t.tid, t.language, t.translation, t.uid_entered, t.uid_approved, t.time_entered, t.time_approved, t.has_suggestion, t.is_suggestion, t.is_active FROM 2_l10n_community_string s LEFT JOIN 2_l10n_community_translation t ON s.sid = t.sid AND t.language = 'cs' AND t.is_active = 1 AND t.is_suggestion = 0 WHERE (s.value LIKE '% contents of this block updates%' OR t.translation LIKE '% contents of this block updates%') LIMIT 0, 10;

My laptop is 2GHz Core 2 Duo, 4MB cache so we may conclude that most server may be 20-30 % faster, but my laptop is not doing anything else while computing these queries...With 5 million translations, this one takes around 20 seconds (Searching for a string at Edit screen).

My first concept was to split databases for every language which immediatelly came to be very dull. My second concept - the current one is much more simple and actually also much more simple to implement:

Split l10n_community_translation table per language

With 5.x and 6.x, we have around 130 000 strings, 180 (constant) languages. If every string in every language is translated, that means 23 million translations. That can happend easily on d.org - not every language and every string but more suggestions per string and release will roll the same number.

What is the gain of splitting? 180 tables, probably less than 200 000 strings in every, that means that the query above will not scan 23m but 200k rows and that's an significant improvement. Actually, these are the numbers for query above:

5m translations: 8 seconds
260k translations: 2 seconds

That is a good improvement...

Pros:
- Much better performance, usually a constant because number of translations for one language wouldn't grow over 200 000 and when that time happens, we will have much different computing power :)
- User is probably willing to wait 2 seconds for a page but not 8.
- Easy to implement basic functionality

Cons and/or coding inconveniences:
- We need an upgrade path. Should be easy to loop through all languages, create tables for them and move their translations there but it is going to take serious amount of time. But we can split that into separate update_60NN() functions for every language and batch API will take care. Is there any other way?
- Computing statistics will be more difficult but it doesn't matter when we cache everything.
- locale_add_language() doesn't give any API so we can't react on creating a language by creating it's translations table. Therefore all tables for every language needs to be created during l10n installation.

What do you guys think?