New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
release-22.1: opt: don't drop LeftJoin filter during join ordering #92103
release-22.1: opt: don't drop LeftJoin filter during join ordering #92103
Conversation
Thanks for opening a backport. Please check the backport criteria before merging:
If some of the basic criteria cannot be satisfied, ensure that the exceptional criteria are satisfied within.
Add a brief release justification to the body of your PR to justify this backport. Some other things to consider:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 2 of 2 files at r1, 2 of 2 files at r2, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @DrewKimball)
The reorderjoins opttester directive previously maintained a map from the first column ID of each base relation to the relation's label in the output. This could cause a panic for relations that didn't output any columns. This patch changes the map to use the relations themselves as keys, which prevents the panic. Release note: None
This patch fixes a bug in the join reordering logic that can lead to incorrect results due to a dropped filter and incorrect conversion of a left join to an inner join. The bug can occur when the join tree contains an inner join with a left join as an input, where the inner join has two separate conjuncts in its ON condition that reference both inputs of the left join. Additionally, the inner join filters must not filter NULL values from the right side of the left join (or alternatively null-rejection rules must be disabled). The incorrect transformation looks something like this: ``` (INNER JOIN xy (LEFT JOIN ab (INNER JOIN uv wz ON v = w) ON b = v) ON a = x AND u = x) ``` => ``` (INNER JOIN ab (INNER JOIN xy (INNER JOIN uv wz ON v = w) ON u = x) ON a = x) ``` Notice how `xy` has been "pushed" into the right side of the left join and the left join's `b = v` filter (and the left join itself) dropped in the process. To understand what causes the bug, it is necessary to understand three points about the join reordering algorithm: 1. Cross products are never introduced in the enumerated plans. So, for two sub-plans, a join is only considered between them if there is an applicable edge between those sub-plans. 2. The original paper associates each join with exactly one edge in the hypergraph that encodes "reorderability" properties. 3. The `JoinOrderBuilder` departs from the paper by associating each inner join *conjunct* with a hypergraph edge. This allows each conjunct to be independently reordered from the others. See the `Special handling of inner joins` section in the `JoinOrderBuilder` comment for more details. (1) combined with (2) implies that a reordered join tree is only considered if every edge in the hypergraph could be applied to form joins in the join tree. This allows the original algorithm to prevent invalid orderings by making just a single edge inapplicable. However, because of (3) the same is no longer true for the `JoinOrderBuilder`. In the example given above, the left join fails the applicability check, indicating an invalid plan. However, the inner join's `a = x` filter passes the check and ends up replacing the left join. This prevents the the check in (1) from catching the invalid plan. This patch fixes the bug by keeping track of the edges that *should* be applied somewhere in each join tree based on the TES of each edge. This is then compared against the actual edges that are applied in the construction of the join tree. If the edge sets aren't equal, the plan is invalid and cannot be added to the memo. This allows the `JoinOrderBuilder` to recover the property that an inapplicable edge invalidates an enumerated plan. Fixes cockroachdb#90761 Release note (bug fix): Fixed a bug existing since 20.2 that could cause incorrect results in rare cases for queries with inner joins and left joins. For the bug to occur, the left join had to be in the input of the inner join and the inner join filters had to reference both inputs of the left join, and not filter NULL values from the right input of the left join. Additionally, the right input of the left join had to contain at least one join, with one input not referenced by the left join's ON condition.
30958b8
to
4f4e4e3
Compare
Updated the test to work for 22.1. I also updated the |
TFTR |
Backport 2/2 commits from #91425.
/cc @cockroachdb/release
opt: use RelExpr instead of ColumnID for reorderjoins relation map
The reorderjoins opttester directive previously maintained a map from
the first column ID of each base relation to the relation's label in
the output. This could cause a panic for relations that didn't output
any columns. This patch changes the map to use the relations themselves
as keys, which prevents the panic.
opt: don't drop LeftJoin filter during join ordering
This patch fixes a bug in the join reordering logic that can lead to
incorrect results due to a dropped filter and incorrect conversion of
a left join to an inner join. The bug can occur when the join tree
contains an inner join with a left join as an input, where the inner
join has two separate conjuncts in its ON condition that reference
both inputs of the left join. Additionally, the inner join filters
must not filter NULL values from the right side of the left join
(or alternatively null-rejection rules must be disabled).
The incorrect transformation looks something like this:
=>
Notice how
xy
has been "pushed" into the right side of the leftjoin and the left join's
b = v
filter (and the left join itself)dropped in the process.
To understand what causes the bug, it is necessary to understand three
points about the join reordering algorithm:
two sub-plans, a join is only considered between them if there is an
applicable edge between those sub-plans.
hypergraph that encodes "reorderability" properties.
JoinOrderBuilder
departs from the paper by associating eachinner join conjunct with a hypergraph edge. This allows each
conjunct to be independently reordered from the others. See the
Special handling of inner joins
section in theJoinOrderBuilder
comment for more details.
(1) combined with (2) implies that a reordered join tree is only
considered if every edge in the hypergraph could be applied to form joins
in the join tree. This allows the original algorithm to prevent invalid
orderings by making just a single edge inapplicable. However, because
of (3) the same is no longer true for the
JoinOrderBuilder
. In theexample given above, the left join fails the applicability check,
indicating an invalid plan. However, the inner join's
a = x
filterpasses the check and ends up replacing the left join. This prevents
the the check in (1) from catching the invalid plan.
This patch fixes the bug by keeping track of the edges that should
be applied somewhere in each join tree based on the TES of each edge.
This is then compared against the actual edges that are applied in
the construction of the join tree. If the edge sets aren't equal,
the plan is invalid and cannot be added to the memo. This allows the
JoinOrderBuilder
to recover the property that an inapplicable edgeinvalidates an enumerated plan.
Fixes #90761
Release note (bug fix): Fixed a bug existing since 20.2 that could
cause incorrect results in rare cases for queries with inner joins
and left joins. For the bug to occur, the left join had to be in
the input of the inner join and the inner join filters had to
reference both inputs of the left join, and not filter NULL values
from the right input of the left join. Additionally, the right input
of the left join had to contain at least one join, with one input not
referenced by the left join's ON condition.
Release justification: low-risk fix for a rare correctness bug in the optimizer