Skip to content
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.2.0: opt: don't drop LeftJoin filter during join ordering #92034

Closed

Commits on Nov 2, 2022

  1. 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.
    
    Release note: None
    DrewKimball committed Nov 2, 2022
    Configuration menu
    Copy the full SHA
    7dd9b8a View commit details
    Browse the repository at this point in the history
  2. 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:
    ```
    (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 #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.
    DrewKimball committed Nov 2, 2022
    Configuration menu
    Copy the full SHA
    8486195 View commit details
    Browse the repository at this point in the history