>> Possible performance drawbacks when dealing with huge MySQL tables?
>The revisions table would be about the size of the present old table.
>It would have some more rows, but would no longer have the overhead of
>duplicate title information. Meanwhile, some functions that deal with
>page titles but don't care about their contents (whatlinkshere,
>allpages, orphans, etc) may well be faster by having a smaller page
>table instead of the text-bloated cur.
Surely most of the current queries done on the database are on cur: logged in and non-logged in users viewing and editing the most recent version of pages. Relatively few queries access old: mostly viewing old versions of pages. I don't know what the exact split is but it is probably 90/10 or something.
By merging cur and old, won't that mean that most of the queries will now access the much larger revisions table? So a relatively small number of queries will get faster, but most will get slower?
Isn't this the original reason for the split of all the page data into the cur and old tables?
I don't know the exact impact combining them back will have to response times. Presumably most of the accesses to revisions will use unique indexes, and will scale well, so maybe the cleaner code is worth it if the access times do not degrade much.
Do any of the developers have a feel for how much slower the queries on revisions would be compared to cur? Just viewing an old revision seems to take about the same time as viewing the current revision, but that is just one piece of code that queries the cur table among many.
-- Michael Richards (Nanobug)