Basically, it ignores the selectivity of the range access being considered.
Consider an example
Let's debug this query:
Put a breakpoint in test_if_cheaper_ordering.
We will have:
- refkey_rows_estimate=21 (this is from range on index a_b)
The selectivity WHERE condition would be about 2%:
This code is executed:
and adjusts select_limit to be: 10 / 0.021 = 476.
The meaning of this number is:
Assuming we are doing a full index scan on an index compatible with ORDER BY clause,
how many records we would need to scan before we get the LIMIT (10) matches we want
Good so far.
Then, we enter get_range_limit_read_cost(... rows_limit=476, ...).
and arrive here:
Look at the if-condition.
It compares the number of rows we will get from the quick select (151 rows, these rows will satisfy a=1) with the rows_limit, which is the number of rows to read before the condition on "a=1" is applied.
This seems wrong.
Instead of rows_limit, we should use "the number of rows to read from quick select, before we find #LIMIT matches".