fallback operations not supported by ch backend in CHHashJoinExecTransformer and CHBroadcastHashJoinExecTransformer
- Dominant language
- Scala
- Stars
- 1.6k
- Forks
- 657
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 85
Description
**Is your feature request related to a problem or challenge? Please describe what you are trying to do.**
some join operations not supported by ch backend, if do not fallback, will trigger errors
**Describe the solution you'd like**
The logic here is that if it is not an equi-join spark will create BNLJ, which will fallback,
if it is an equi-join, spark will create BroadcastHashJoin or ShuffleHashJoin or SortMergeJoin,
for these join types, we need to filter For cases that cannot be handled by the backend,
1 there are at least two different tables column and Literal in the condition Or condition for comparison
for example (a join b on a.a1 = b.b1 and (a.a2 > 1 or b.b2 < 2) )
2 tow join key for inequality comparison (!= , > , <)
for example
(a join b on a.a1 > b.b1)
There will be a fallback for Nullaware Jion
For Existence Join which is just an optimization of exist subquery, it will also fallback
Contributor guide
Research direction
Start by reading CHHashJoinExecTransformer and CHBroadcastHashJoinExecTransformer, focusing on how join conditions and join types are selected. Check the listed non-equi, compound OR, null-aware, and existence join cases against backend support. Done means unsupported cases consistently fall back instead of triggering backend errors.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- clickhouse, scala
- Domain
- backend, databases
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100