On September 12th, 2006 Sheeri (not verified) says:
Scott -- The section of the manual you're looking at compares =, , , etc.
For instance, if you give the optimizer
WHERE expr=1 OR expr=2
that uses equality. If you give the optimizer
WHERE expr IN (1,2)
what does it use? Well, obviously to us, equality. What it says is that if you use constants instead of functions, etc. then it will go faster. It's intuitive that quality comparisons (like expr=1) go faster.
What the internals manual states is that it doesn't matter how you write it, because they will be processed the same way. If you have a constant in the IN statement, or a constant in each part of the OR, it's faster, no matter what. But there's no difference to the optimizer between using IN() or a bunch of OR statements.
I find using IN() to be more readable than a bunch of OR statements.
Scott -- The section of the
Scott -- The section of the manual you're looking at compares =, , , etc.
For instance, if you give the optimizer
WHERE expr=1 OR expr=2
that uses equality. If you give the optimizer
WHERE expr IN (1,2)
what does it use? Well, obviously to us, equality. What it says is that if you use constants instead of functions, etc. then it will go faster. It's intuitive that quality comparisons (like expr=1) go faster.
What the internals manual states is that it doesn't matter how you write it, because they will be processed the same way. If you have a constant in the IN statement, or a constant in each part of the OR, it's faster, no matter what. But there's no difference to the optimizer between using IN() or a bunch of OR statements.
I find using IN() to be more readable than a bunch of OR statements.