Hmm, I'm starting to get a bit worried about the potential to create queries that are impossible in a way that's hard to detect, or that return very few results. Such queries, if unindexed, could get very slow.

For example, it seems like it's not possible to have a log entry be associated with an anon (at least in default setups where anons can't move, delete, etc). If you filtered to log entries only (by hiding everything else), then set hideliu=1, MySQL has to examine every single row in the RC table before it figures out that there are no rows matching these criteria. In other cases, if results are really rare, a lot of rows need to be examined before 50 (or 500) matches are found; damaging edits by bots, for example, could be in this category.

hidehumans=1&hideothers=1 is another good example: it'll result in rc_bot=1 AND rc_user_text='Catrope', and if I am not a bot user, there won't be any such rows, Thankfully, there is an index on rc_user_text so we only have to examine all of my rows (as opposed to the entire table), but that won't be true in all cases (there's no index on rc_user, for example, so hideliu=1&hidehumans=1 is also going to fail).

We should figure out what indexes we need or what strategy we should use to keep query slowness under control.

@SBisson @Mattflaschen-WMF @Mooeypoo

Part of the solution might be to identify filter combinations that will return zero results, not because they contain opposite filters (hidebots && hidehumans) but because the system doesn't allow certain combinations to happen in the data (hideliu && hidehumans) and short-circuit them in the code instead of running a slow and useless query.

I don't know what are those combinations.

Here's a list of the filters with associated db columns for reference:

I'm not exactly sure how this game is played, but, the following combinations seem vanishingly unlikekly (to the best of my understanding):

• Minor edits + any of the following: categorization edits, log edits
• Log actions + Very likely bad or Very likely bad faith (if I understand log actions properly)