[DISCUSSION]: Unified approach for joins to output batches close to `batch_size`
- Dominant language
- Rust
- Stars
- 9.3k
- Forks
- 2.4k
- Avg merge
- 3d 7h
- Merged PRs (30d)
- 344
Description
`BatchCoalescer` is not used in joins yet, since CoalesceBatchesExec appears after the joins having filter, in case of the output batches might have a lower row count than target batch size. So, why cannot we follow the same pattern in SMJ? If collecting batches in the join itself is more performant, then we should also refactor the other joins as well?
On the other hand, `BatchSplitter` is used in other joins, and SMJ could (should) have it too, as there is no other way of splitting the batches according to target batch size.
I've thought about this, and I believe the most optimal solution is to make all join operators capable of performing both coalescing and splitting in a built-in manner. This is because the output of a join can either be smaller or larger than the target batch size. Ideally, there should be no need (or only minimal need) for CoalesceBatchesExec.
To achieve this built-in coalescing and splitting, we can leverage existing tools like BatchSplitter and BatchCoalescer (although there are no current examples of BatchCoalescer being used in joins). My suggestion is to generalize these tools so they can be utilized by any operator and applied wherever this mechanism is needed. As this pattern becomes more common, it will be easier to expand its usage and simplify its application.
_Originally posted by @berkaysynnada in https://github.com/apache/datafusion/issues/14160#issuecomment-2601723615_
Contributor guide
Research direction
Start by reading the related discussion in issue 14160 and compare how BatchCoalescer, BatchSplitter, and CoalesceBatchesExec are used around the joins, especially SMJ. Determine a unified approach for join operators to split and coalesce output batches near the target batch size, with minimal need for CoalesceBatchesExec; done means the approach is agreed and consistently applicable across joins.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- databases
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100