| • bzimport | |
| Apr 17 2007, 11:30 AM |
Author: jmetillon
Description:
There's an option available at the Special:Recentchanges page that allows to
hide minor changes. The parameter is hideminor=1.
But on Special:Contributions/User, the parameter is not available. I think it
would be helpful to hide minor changes in user contributions page also.
Thank you.
Version: unspecified
Severity: enhancement
robchur wrote:
Note that we don't have an index on revision.rev_minor_edit at the moment; we'll want to include it in the relevant indices.
ayg wrote:
I don't think an extra index is useful, unless a large percentage of rows are minor edits. It would probably be better to scan twice as many rows, rather than add an entire extra index.
(In reply to comment #2)
I don't think an extra index is useful, unless a large percentage of rows are
minor edits.
Well, that might be fairly likely for maintenance bots that make large numbers of minor edits.
ayg wrote:
Hmm, true, that would scan all of that user's contribs, since this is per-user. But I'm not sure where we'd add the column to the index. usertext_timestamp is (rev_user_text, rev_timestamp). If we make it (rev_user_text, rev_minor_edit, rev_timestamp) that breaks ordering by rev_timestamp for when we don't specify rev_minor_edit: we'd have to do rev_minor_edit IN (0,1) for other queries, and range scans break ordering, it would be a filesort. It would be better in MySQL 4 to rewrite as a UNION, but then you need to query twice the rows anyway. Whereas if we do (rev_user_text, rev_timestamp, rev_minor_edit), it can't use the index to retrieve by rev_minor_edit while ordering by rev_timestamp, which defeats the point.
I would ask Domas. :) I suspect this is impractical without adding an entirely separate index for it, since as you point out we can't rely on scanning rows here. If he doesn't have any bright ideas, I guess this is WONTFIX, at least for Wikipedia. This is the kind of thing it would be nice for smaller sites to have, though, which don't mind scanning a whole bunch of rows, if it really isn't possible to get this to work reasonably on the large sites. So maybe this should still be done for $wgMiserMode = false by just scanning the rows, icky though that may be.
This would be very useful in page histories, too.
It could be implemented as an option (to be disabled for very large wikis), couldn't it? Nobody has more efficient ways than the ones found three years ago?
Marking it as LATER.
Switching from LATER to the second most relevant resolution for fear of information loss. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65116