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