Am Fre, 2002-11-01 um 15.11 schrieb Brion VIBBER:
My little old PII Linux box isn't bad-ass enough
for me to dare putting
the huuuge English Wikipedia database on it, so I just did some quick
tests with the smaller Danish and German dbs. Using the recentchanges
table seems to be consistently a few percent faster than reading
straight from cur and old, but not significantly so. (This may just be
the difference in overhead between querying two tables versus one.)
Under load and with a larger database, there may or may not be a more
pronounced difference.
I'll try this with the full DB on Monday, I can't do it immediately
because I have to build the RC table first, which will probably take a
while.
Erik Moeller wrote:
> There should be an INDEX on the rc_timestamp column.
This is not done in the default table build, but the index is created in
the recentchanges build script. Since I haven't run that yet, my table
still lacks the index. Sorry about the confusion.
However it's also teling me "Using
filesort", which I get the impression
is a bad thing.
The MySQL manual has a page on this:
http://www.mysql.com/doc/en/ORDER_BY_optimisation.html
I don't see how any of the conditions they list for when the index
cannot be used to resolve ORDER BY is true in our query, though. In any
case, my guess is that this doesn't significantly affect performance as
we are dealing with fairly small sets of data that need to be sorted.
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS -
http://www.berlios.de