apache / apache/gluten

fallback operations not supported by ch backend in CHHashJoinExecTransformer and CHBroadcastHashJoinExecTransformer

Open
#1,251 0 comments 0 reactions 0 assignees View on GitHub
enhancement stale
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.