opt: fix incorrect results from zigzag join with different index directions #97151
Conversation
…ctions
Prior to this commit, the optimizer could plan a zigzag join between two
indexes where the matching column(s) had ascending values in one index and
descending values in the other. This could cause incorrect results, because
it broke an assumption of the zigzagJoiner.
For example, consider this table and query:
CREATE TABLE t (
c INT NOT NULL,
l INT NOT NULL,
r INT NOT NULL,
INDEX (l ASC, c DESC),
INDEX (r ASC, c ASC)
);
INSERT INTO t VALUES (1, 1, -1), (2, 1, -2);
SELECT * FROM t@{FORCE_ZIGZAG} WHERE l = 1 AND r = -1;
This query should produce 1 row, but prior to this commit it produced 0
rows. This was due to the fact that the direction of c was different between
the two indexes.
This commit fixes the issue by preventing the optimizer from planning a
zigzag join in such cases.
Fixes cockroachdb#97090
Release note (bug fix): Fixed a bug in the query engine that could cause
incorrect results in some cases when a zigzag join was planned. The bug could
occur when the two indexes used for the zigzag join had a suffix of matching
columns but with different directions. For example, planning a zigzag join with
INDEX(a ASC, b ASC) and INDEX(c ASC, b DESC) could cause incorrect results.
This bug has existed since at least v19.1. It is now fixed, because the
optimizer will no longer plan a zigzag join in such cases.
|
This change is |
There was a problem hiding this comment.
Thanks for the quick fix!
Reviewed 4 of 4 files at r1, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @mgartner)
There was a problem hiding this comment.
TFTR! Friendly ping, @mgartner.
Reviewable status:
There was a problem hiding this comment.
Going to go ahead and merge this since it's a low-risk change and I want to get the fix backported.
bors r+
Reviewable status:
|
Build failed: |
There was a problem hiding this comment.
Unrelated flake (I will open an issue shortly)
bors r+
Reviewable status:
|
The flake is me from a recently merged #96695, I'll take a look, no need for an issue. |
|
Thanks! |
|
Build succeeded: |
Prior to this commit, the optimizer could plan a zigzag join between two indexes where the matching column(s) had ascending values in one index and descending values in the other. This could cause incorrect results, because it broke an assumption of the
zigzagJoiner.For example, consider this table and query:
This query should produce 1 row, but prior to this commit it produced 0 rows. This was due to the fact that the direction of
cwas different between the two indexes.This commit fixes the issue by preventing the optimizer from planning a zigzag join in such cases.
Fixes #97090
Release note (bug fix): Fixed a bug in the query engine that could cause incorrect results in some cases when a zigzag join was planned. The bug could occur when the two indexes used for the zigzag join had a suffix of matching columns but with different directions. For example, planning a zigzag join with
INDEX(a ASC, b ASC)andINDEX(c ASC, b DESC)could cause incorrect results. This bug has existed since at least v19.1. It is now fixed, because the optimizer will no longer plan a zigzag join in such cases.