Repository navigation
fix join and unnest planning to ensure that duplicate join prefixes are not used - #13943
Conversation
clintropolis
changed the title
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| .build() | ||
| ), | ||
| "j0.", | ||
| equalsCondition(makeColumnExpression("__time"), makeColumnExpression("j0.d0")), |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation
| .build() | ||
| ), | ||
| "j0.", | ||
| equalsCondition(makeColumnExpression("__time"), makeColumnExpression("j0.d0")), |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation
| .build() | ||
| ), | ||
| "j0.", | ||
| equalsCondition(makeColumnExpression("__time"), makeColumnExpression("j0.d0")), |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation
| .build() | ||
| ), | ||
| "j0.", | ||
| equalsCondition(makeColumnExpression("__time"), makeColumnExpression("j0.d0")), |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation
gianm
left a comment
gianm
left a comment
There was a problem hiding this comment.
The fix LGTM. It looks like a pre-existing bug with join planning: because we're only looking at the row signature when determining what rightPrefix to use, we might choose a prefix that was used for a join where no RHS columns were selected. (Like an inner-join-used-as-filter, as in your test case.)
| "j0.", | ||
| equalsCondition(makeColumnExpression("v0"), makeColumnExpression("j0.v0")), | ||
| "_j0.", | ||
| equalsCondition(makeColumnExpression("v0"), makeColumnExpression("_j0.v0")), |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation
| "j0.", | ||
| equalsCondition(makeColumnExpression("v0"), makeColumnExpression("j0.v0")), | ||
| "_j0.", | ||
| equalsCondition(makeColumnExpression("v0"), makeColumnExpression("_j0.v0")), |
Check notice
Code scanning / CodeQL
Deprecated method or constructor invocation
…re not used (apache#13943) * fix join and unnest planning to ensure that duplicate join prefixes are not used * wont somebody please think of the children
3 participants
Description
This PR fixes a join query planning regression caused by #13902. After that change, this query will actually plan "correctly" but then later explode due to duplicate join prefix. The planner was selecting a join prefix only looking at the
RowSignatureof the left and right side datasources, but if those queries had any nested join prefixes, the query would later fail because the native prefix checker flattens the join to check prefixes (so losing the context of what is used directly in outside layers).The solution Ive added is to just dig through the datasources to extract any existing prefixes and add that to the checked set when selecting new prefixes, to ensure the planner never picks duplicate prefixes even if it can't see them at the top level.
The added test plans and produces the same result as prior to #13902. Full disclaimer, I didn't actually work out the answer by hand to ensure that it was correct (the repro query was relayed to me), but at least it isn't different than before the change 😅 .
This PR has: