Change Details

The query for the compare check performs a subquery for each target and aggregates the resulting rows. The subqueries are limited so that no more than 100k rows will be aggregated. In {T248588}, we found that the query was slower than expected in extreme circumstances (large `cu_changes` table, checking prolific users/IPs). Lowering the limit to 25,000 rows brought the time taken into a more acceptable range, and would still be an improvement on the existing CheckUser tool, which has a limit of 5000.

The query for the compare check performs a subquery for each target and aggregates the resulting rows. The subqueries are limited so that no more than 100k rows will be aggregated. In {T248588}, we found that the query was slower than expected in extreme circumstances (large `cu_changes` table, checking prolific users/IPs). Lowering the limit to 25,000 rows brought the time taken into a more acceptable range, and would still be an improvement on the existing CheckUser tool, which has a limit of 5000. We should control the limit with a config so that we can test different limits and so that we can use different limits on different wikis. 25,000 would probably be a good default to start with.

The query for the compare check performs a subquery for each target and aggregates the resulting rows. The subqueries are limited so that no more than 100k rows will be aggregated. In {T248588}, we found that the query was slower than expected in extreme circumstances (large `cu_changes` table, checking prolific users/IPs). Lowering the limit to 25,000 rows brought the time taken into a more acceptable range, and would still be an improvement on the existing CheckUser tool, which has a limit of 5000. We should control the limit with a config so that we can test different limits and so that we can use different limits on different wikis. 25,000 would probably be a good default to start with.