To discuss:
In some cases, providing the highlight classes requires an extra join. So we may want to only do that join on demand.
This would require (sometimes - this could be annotated, so the frontend knew when it needed to reload) reloading the results when highlights change, which is a cost of its own.
See T176228: Special:RelatedChanges with edit filters has query error due to missing join on page table
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • DannyH | T171977 Annual Plan 2017-2018, Audiences 5: Increase current editor retention and engagement | |||
| Resolved | • DannyH | T171981 Annual Plan 2017-2018, Audiences 5, Goal 2: Give better ways to monitor contributions | |||
| Resolved | • jmatazzoni | T157642 Graduate New Filters UX out of beta on Recent Changes on ALL wikis | |||
| Resolved | Krinkle | T176652 Performance review of RCFilters feature | |||
| Open | None | T168887 Filter users' edits by status | |||
| Open | None | T167698 Filter blocked users' edits | |||
| Open | None | T176385 Improve New Filters performance by changing DB query based on highlights? |
let's consider this and see if we think it would make much difference. @Catrope, what do you think?