I am glad the tables are useful, hopefully stimulating more positive
use of the thanks notifier by contributors.
The reports are updating *slowly*, currently at April 2014... This is
in part because of the WMFlabs outage yesterday, though in general any
report of the "logging" table is going to be slow (it is the largest
table on the wiki database). The first run-through will take several
days as it is going back through all of 2014. Once it is only
reporting on the previous month, I suspect it will finish monthly
updates within the first first day.
Hmm, I'm not sure how you're measuring largest, but I imagine on most
wikis there are more rows in the revision table than there are in the
logging table. For example, on the English Wikipedia, there are
approximately 598,859,006 rows in the revision table and 62,731,285 rows
in the logging table. I suspect on most wikis, revision, text, and maybe
archive would typically be larger than logging, except in weird cases
such as loginwiki[_p]. And then of course there are the *links tables. But
it depends on whether you're comparing size on disk or number of rows.
You probably want to use logging_userindex instead of logging. The former
is typically significantly faster due to the way we use table views.
I have a bit of experience with database reports. Off-hand I'd say it
should be possible to query all of this information in under an hour. With
the index on logging[_userindex].log_action, even a large table such as
logging shouldn't be too awful to query for this information. If you have
queries that are taking a very long time, we should probably investigate.