Am Mit, 2002-10-30 um 13.28 schrieb Brion VIBBER:
>Those should be fixed. Any other problems?
I tweaked GlobalFunctions.php, Article.php, and SpecialMovepage.php to
update the recentchanges database on page deletion, image upload, and
page rename. The RC behavior on renames over existing redirect pages is
slightly different, and may or may not be more user-friendly than the
current behavior.
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 haven't installed any of this on the live server; somebody please
check out the updates in CVS and look 'em over to make sure nothing else
is broken.
Erik Moeller wrote:
There should be an INDEX on the rc_timestamp column.
Hmm... I'm not sure how to go about doing this. EXPLAIN already
indicates that it's using rc_timestamp as the key, and creating an index
vai CREATE INDEX or ALTER TABLE ADD INDEX doesn't seem to change
anything except to add more to the list of 'possible keys'.
However it's also teling me "Using filesort", which I get the impression
is a bad thing.
I think we should adopt a principle similar to
KeptPages for RC logs,
that is, to maintain a consistent log for 14 days or so, no matter how
many entries happen in those days, instead of just saying "the last 5000
changes". So I guess we should just DELETE FROM the RecentChanges table
all entries that are older than n days regularly.
At ~2000 edits a day, that's a lot of entries...
-- brion vibber (brion @
pobox.com)