Erik Moeller wrote:
Timwi-
Are you sure the size makes it slow? The way I understand it, it doesn't; if you split it up into several tables, it'll still have to organise those different tables.
It certainly will, but it won't have to perform, e.g., a fulltext search on the entire index, but only on the index for that table.
First of all, I have to admit I was was being short-sighted again by forgetting to consider fulltext searches. My apologies.
However, I'm not convinced that this really matters. It would only have to search on the entire fulltext index if you actually wanted to search the entire table (an inter-language search). If you had an integer column that specifies the language of an article, and an index on that, then searching only the English text would be equal in speed to having a separate table for the English text.
At least this is how I understand it. Of course I may well be wrong. I'll ask a MySQL expert later on, when he's online :-)
Compare the fulltext search of the English wiki with the one on the German wiki -- that is certainly no O(log n) scalability.
No, certainly not. What I said about O(n) and O(log n) applies to selection of a single row from a simple key on a fixed-length column. What I was thinking of was combining the tables to form one whole Wikipedia database so we could have one single Watchlist and one inter-language Recent Changes page. Then generating an English-only Recent Changes page from the combined table should not be slower as it is now.
Timwi