You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similar to #1939, HashJoinExec drives its first child to completion within HashJoinExec::execute, see here, instead of returning a stream that performs this operation lazily.
This effectively stalls out constructing the rest of the physical plan until the child has been fully evaluated, and prevents result streaming from working correctly. It is also highly probable that one could construct a diamond shaped plan that would block indefinitely as a result.
To Reproduce
Run query incorporating a join
Expected behavior
ExecutionPlan::execute should return a stream of results, but should not block on those results being available
Additional context
I am currently experimenting with custom scheduling of physical plans, and this requires the construction of the physical plan to be correctly decoupled from its evaluation
The text was updated successfully, but these errors were encountered:
Describe the bug
Similar to #1939,
HashJoinExec
drives its first child to completion withinHashJoinExec::execute
, see here, instead of returning a stream that performs this operation lazily.This effectively stalls out constructing the rest of the physical plan until the child has been fully evaluated, and prevents result streaming from working correctly. It is also highly probable that one could construct a diamond shaped plan that would block indefinitely as a result.
To Reproduce
Run query incorporating a join
Expected behavior
ExecutionPlan::execute
should return a stream of results, but should not block on those results being availableAdditional context
I am currently experimenting with custom scheduling of physical plans, and this requires the construction of the physical plan to be correctly decoupled from its evaluation
The text was updated successfully, but these errors were encountered: