This PR poses an alternative to #389 that doesn't require changing the way effort is counted in the join operator. Instead it adds a JoinCore::join_core_yielding operator that allows specifying a yield_function to control the join's yield behavior, similarly to how the half join operator is configurable. The yield_function enables yielding based on time and number of produced records.
The yield_function replaces the previous fueling concept used by the join operator. Higher-level join operators that don't explicitly specify a yield_function still have the old behavior of yielding after 1 million produced records, so backwards-compatibility is maintained for all but direct users of join_core_internal_unsafe.
Some additional care is taken to ensure the yield_function is only checked after the join has made some progress. This is to avoid stuck joins caused by overly aggressive yield_functions. However, nothing prevents users from shooting themselves in the foot by specifying an overly lenient yield_function (e.g. one that always returns false) and then potentially running into OOMs. The current implementation can easily be modified to enforce a yield when the effort reaches a hardcoded value, if we think this safeguard would be valuable.
This PR poses an alternative to #389 that doesn't require changing the way effort is counted in the join operator. Instead it adds a
JoinCore::join_core_yieldingoperator that allows specifying ayield_functionto control the join's yield behavior, similarly to how the half join operator is configurable. Theyield_functionenables yielding based on time and number of produced records.The
yield_functionreplaces the previous fueling concept used by the join operator. Higher-level join operators that don't explicitly specify ayield_functionstill have the old behavior of yielding after 1 million produced records, so backwards-compatibility is maintained for all but direct users ofjoin_core_internal_unsafe.Some additional care is taken to ensure the
yield_functionis only checked after the join has made some progress. This is to avoid stuck joins caused by overly aggressiveyield_functions. However, nothing prevents users from shooting themselves in the foot by specifying an overly lenientyield_function(e.g. one that always returnsfalse) and then potentially running into OOMs. The current implementation can easily be modified to enforce a yield when the effort reaches a hardcoded value, if we think this safeguard would be valuable.