ayg wrote:

This would require tracking all groups; currently it's hard-coded to only track admins. NUMBEROFADMINS does not scan the user_groups table. That doesn't scale. Rather, it retrieves a column from the one-row site_stats table, which contains a fixed set of info (number of pages, number of articles, number of users, number of admins, ...). Probably this doesn't scale to arbitrary groups, so we might need a new table for this.

ayg wrote:

Also, {{NUMBERINGROUP}} is a clearer name. Or we could give an optional parameter to {{NUMBEROFUSERS}} or something. {{USERSINGROUP}} suggests it would give a list.

artificial wrote:

(Ooops, lol, I've just realised the alternate interpretation of the name I suggested: "USER SIN GROUP", reminds me of that "Admin is traitor" thing.)

I'm not terribly familiar with MediaWiki's internals, but there can't be more than about 2,500 group assignments even on all of the English wikipedia; would a table scan really affect the servers?

A whole new table, if it had to be used, would be a nuisance because it's an extra thing to have to manage and update. It would probably only need to be done in one place though, rebuilding the table info with a single SELECT/GROUP BY query in the user rights change code.

ayg wrote:

It's true that you'd just have to scan a few hundred to a couple thousand index leafs. I don't know if that would be acceptable or not. Even on the toolserver it manages to run in <10 ms, so probably it would be <<1 ms on the real servers. Regardless, it might not do so well when we accumulate tens or hundreds of thousands of rollbackers in a couple of years. It's best to do it right to begin with, all around, if it's to be done.

soxred93 wrote:

Fixed in r40116