Each index, as you suggested them, contains data on the respective field only (one on quantity, another one on urgency). There is no information about urgency in the quantity index and vice versa. You should look that up in the table.

Of course you could make both indexes covering, but this would still require you to scan 5k records (instead of but 25).

I’m missing why it would need to do any record look-ups when all the data is contained in 2 indexes. Table lookups would only happen once the RIDs had been calculated via index lookup ops.

That’s 5000 records (from 1 to 5000)

Then it would either do a table scan **only on the relevant records** to filter urgency,

Urgency is not a part of the index on quantity. We’ll have to do a table lookup for each of 5000 records, each of them being about five times as costly.

Better, it would do a walk-through on the urgency index, find all records for “<= 4″, and then perform an index intersect on the two index result sets, giving us the RIDs we’re looking for

That’s another 5000 records, plus the overhead of a join between the resultsets — opposed to 25 (twenty five) index seeks in a composite index with an IN rewrite.

I don’t see why it needs to scan 40k records.

If we substitute 5 with 20 (as in your original comment), we’ll get 40k vs 400. If we leave 5 as is, we’ll get 10k vs 25.

I thought that < 20 would have done exactly what IN () is doing

IN() on what column type?

If the column type is, say, FLOAT, the smallest superset of the values that satisfy the condition is close to infinity (I know this is wrong in math sense, but you know what I mean). It’s infeasible to convert the range into the set.

If the type is UNSIGNED INT then of course it can and sometimes needs to be done.

No optimizer known to me is able to do it, if that was your question, that’s why I wrote this article.

On a related point, if those columns were individually indexed, as opposed to indexed as you have done with low cardinality, would we still be looking at the scenario you outline here?

The optimizers are capable of doing INDEX_INTERSECT, that is selecting the recordsets satisfying each condition separately then joining these recordsets. This would require scanning 20000 + 20000 = 40000 records plus overhead of joining them, as opposed to just 400 records with a range rewrite.

On a related point, if those columns were individually indexed, as opposed to indexed as you have done with low cardinality, would we still be looking at the scenario you outline here?

Thanks for the good work.

Just curious to know how does these number works with “joins” (many-tables).