Change Details

As discussed at T399458#11122178, slow query logs for Special:RecentChanges show expensive queries with narrow ORES criteria, usually involving an intersection of "good faith" and "damaging" scores. If ORES stored the result of threshold comparisons instead of scores, the two scores could be combined into a single index which would allow the intersections to be efficiently queried. If ORES had a table of recent comparison results, purged when recentchanges is purged, some of the intersections would be small enough to allow the ORES summary table to be placed first in the Special:RecentChanges join, for a 10x performance improvement.

As discussed at T399458#11122178, slow query logs for Special:RecentChanges show expensive queries with narrow ORES criteria, usually involving an intersection of "good faith" and "damaging" scores. If ORES stored the result of threshold comparisons instead of scores, the two scores could be combined into a single index which would allow the intersections to be efficiently queried. Some of the intersections would be small enough to allow the ORES summary table to be placed first in the Special:RecentChanges join, for a 10x performance improvement.

As discussed at T399458#11122178, slow query logs for Special:RecentChanges show expensive queries with narrow ORES criteria, usually involving an intersection of "good faith" and "damaging" scores. If ORES stored the result of threshold comparisons instead of scores, the two scores could be combined into a single index which would allow the intersections to be efficiently queried. If ORES had a table of recent comparison results, purged when recentchanges is purged, someSome of the intersections would be small enough to allow the ORES summary table to be placed first in the Special:RecentChanges join, for a 10x performance improvement.