Repository navigation
Use MemoryManager in Join operators, and return errors if the memory budget is exceeded #5220
Description
See description on #3941
The idea is to apply the same treatment to Join operators that was done to GroupBy in #3940 and throw an error if their memory budget is exceeded rather than unlimited allocating.
All the operators in https://github.com/apache/arrow-datafusion/tree/master/datafusion/core/src/physical_plan/joins need to be evaluated.
Items to do:
- Apply limits to NLJ Ignoring of memory-pool limits & OOM on large cartesian-product join #5162
- Apply limits to Cross Join
- Apply limits to Hash Join
- Apply limits to Sort Merge Join
cc @DDtKey and @crepererum who have expressed interest in this project in the past
Activity
DDtKey commentedon Mar 14, 2023
Amazing, it looks like only sort-merge join is left!
Thanks @korowa 🚀
korowa commentedon Mar 17, 2023
Actually there is also
SymmetricHashJoinExec-- but, I suppose, its memory management is a bit more complicated and may be behind the scope of this issue:SymmetricHashJoinExec-- if my understanding is correct -- main use case for this operator is joining two unbounded sources (streaming jobs), and from this point of view it doesn't make much sense to limit memory without any spilling fallbacks (subjectively, it doesn't seem correct to fail data streaming job in case of memory overallocation attempt)My proposal here would be to file separate issue for
SymmetricHashJoinExecmemory management, and (as I see it) implement memory limitation along with data spilling. Maybe, we can go for it when we have reliable spilling forHashJoinExec, however, prior to it is also an option.@ozankabak, @metesynnada it would be great to hear your thoughts on it.
ozankabak commentedon Mar 17, 2023
At a quick glance, this sounds reasonable. But we will do some deeper thinking on this and come back to share our thoughts.
alamb commentedon Mar 18, 2023
Filed #5636 for memory management of symmetric hash join