Prefer equality in boolean comparisons #34166
Conversation
| @@ -839,7 +839,7 @@ public override async Task Rewrite_compare_bool_with_bool(bool async) | |||
| """ | |||
| SELECT "e"."Id" | |||
| FROM "Entities1" AS "e" | |||
| WHERE "e"."BoolA" <> "e"."NullableBoolB" | |||
| WHERE "e"."BoolA" = (NOT ("e"."NullableBoolB")) | |||
There was a problem hiding this comment.
Is this a positive change? I doubt any database out there will use index with equality and NOT, more than it would for inequality, no? Should we make this change more targeted, so that it doesn't do this specific transformation?
There was a problem hiding this comment.
Is this a positive change?
It is a positive change, at least as long as we do not analyze the provenance of the columns.
In this specific case, it is basically irrelevant: the whole table is going to be scanned linearly (just once).
If the left column and the right column came from different tables, it would be much more efficient.
I doubt any database out there will use index with equality and NOT, more than it would for inequality, no?
At least Sqlite does. This is basically an instance of #34048 (comment)
Should we make this change more targeted, so that it doesn't do this specific transformation?
Do you expect worse plans on some db?
There was a problem hiding this comment.
I'll add some examples in the issue #34164.
There was a problem hiding this comment.
Added Sqlite and Postgres examples 🚀
There was a problem hiding this comment.
So between a <> b and a = NOT(b), the former certainly seems more natural, and what I'd expect a standard SQL query to look like. If these perform the same, I'd definitely prefer the first, at least for readability etc. (and we do generally care about that).
I could alsi imagine a database where the planner optimizes to use an index on b (effectively transforming the inequality into a not on a), where this change would cause a regression. of course, this is entirely speculative, and I have an actually looked into which databases basis to which optimizations.
I'd prefer us to do a bit more cross database research before merging a change like this, which at the very least makes our SQL less readable/standard/expected (and that does tend to have some correlation sometimes with performance). If this address is a very specific Sqlite behavior, where equality is always better, we always have the option of doing this change for sqlite only.
There was a problem hiding this comment.
OK, I wrote the above comment before noticing you posted data on other databases… some remarks:
- For the Sqlite case, have you confirmed that the second option, where an index is built, is actually faster than the first?
- For the SQL Server case, the total subtree cost is actually higher with the second method.
There was a problem hiding this comment.
I will perform some measurement, but I do not have real code/an actual database that is using this filter; I will try to do some synthetic examples (I'll try to cover some interesting cases, but a real-world case would definitely be more relevant).
There was a problem hiding this comment.
Some (synthetic) benchmarks have been posted in #34164
|
Maybe I should have explained this in advance: this is not a new/different approach to translate boolean (in)equalities; it is just making the code more consistent in choosing Ideally there should be no duplication of this code, hence it should be "inevitably" consistent. |
ranma42
force-pushed
the
prefer-equal
branch
2 times, most recently
from
7f57ec3 to
32d05b3
Compare
|
I cleaned up the code a little (the same equality conversion logic is now shared between |
|
Rebased to resolve conflicts |
ranma42
force-pushed
the
prefer-equal
branch
from
b79642e to
09f58e6
Compare
|
Rebased to resolve conflicts |
…Entities Problem was that in EF9 we moved some optimizations from sql nullability processor to SqlExpressionFactory (so that we optimize things early). One of the optimizations: ``` !(true == a) -> false == a !(false == a) -> true == a ``` is not safe to do when a is a constant or parameter null value, because it evaluates to true IS NULL (two value logic). Fix is to remove this optimization from SqlExpressionFactory and instead put it back into OptimizeNotExpression, once we've converted everything we could to IS NULL checks already. Fixes dotnet#35393
They can take advantage of indexing.
These are the baselines regenerated after a rebase on top of 35fc423.
|
This is currently marked as draft as it is based on (an old version of): |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
👍 @maumar your fix is still needed, at least the part that drops the invalid optimization from |
In most databases, equality comparisons can take advantage of indexing and inequalities cannot.
Fixes #34164.