Ineed, I was worried about the same issue.
I've just committed some changes to that affect.
From: "R. S. Shaw" <shaww(a)inbox.com>
Reply-To: Wikimedia Quality Discussions <wikiquality-l(a)lists.wikimedia.org>
Subject: [Wikiquality-l] a DB addition for performance and more
Date: Sun, 15 Apr 2007 19:35:39 -0800
I've been perusing some of the FlaggedRevs code recently (as it has
evolved). It seems to be heading in a good direction. I'm not sure what
ideas have been rumbling around in all your heads, but I thought I'd share
the following thought with you in case it hasn't been brought up yet.
Performance is likely to be something of an issue, and will become more so
as the database becomes populated with growing numbers of flagged
revisions. Obviously the most common operation is to display the default
version of an article. With FlaggedRevs this involves joining rows from
the flaggedrevtags, flaggedrevs, and revision tables in a nontrivial
database operation. The idea is to mostly avoid this with an additional
The table in its simplest form would just have two or three columns:
PageID (primary key)
RevID of the "latest stable revision" by namespace criteria
Valid flag for above RevID (or coded by NULL in revid, etc)
A default-revision access would go directly to this table and if a valid
revid is found would then pick up the text of the page from the flaggedrevs
table. If not found, the access would proceed as in the current approach.
Possibly the access itself should put the resulting revid into the above
shortcut table, but maybe this update would be done by a background task,
or just by review-updates.
Once filled in, the default-revision access should be much better, even for
only occasionally-accessed pages. Having this table requires that an
update to the revid or valid flag be done when a page is given a new review
setting, so that the new shortcut table will not persistently yield a wrong
Now, all that seems good, but this table also should help with support of
the number one wishlist item, per-page default-selection criteria. The
shortcut table could record the criteria to be used for the page, perhaps
in a text form convertable to the $wgFlaggedRevTags PHP variable which
controls the selection.
With that in the table, a default-revision access would again use the
revision found if it is set, otherwise select the revision using the
page-specific criteria if they are present (otherwise the namespace
default, of course). The table would also then be used in the other
various flagged-revision queries, since it would be the residence of the
per-page revision selection criteria.
I'd guess this idea has no particular implications for the early
implementation now advancing rapidly, but it might be useful to ponder for
work a bit down the road.
Wikiquality-l mailing list
MSN is giving away a trip to Vegas to see Elton John. Enter to win today.