Is your feature request related to a problem? Please describe.
Mixed joins previously ran fused AST and join kernels that suffered low occupancy from register pressure. Three components were monomorphized and fully inlined into one kernel body, keeping many values live at once: cuco's probing kernels, the row operators, and the AST evaluator.
#23012 split that into hash_join followed by filter_join_indices (#20385), so no single kernel carries all three. The join kernel keeps cuco and the row operators, the filter kernel carries only the AST evaluator. The cost is that the join now materializes the full unfiltered index pair before filtering it.
Describe the solution you'd like
#23640 replaces cuco's templated kernels with a hand-rolled table and four purpose-built kernels, removing one source from the join side. A re-fused kernel would therefore carry the row operators and the AST evaluator, but not cuco. Evaluate whether that pair fits in a register budget that still gives acceptable occupancy.
The win is not fewer passes; HashCSR is count, scan, fill, probe-count, scan, retrieve either way. It is that a fused retrieve never materializes the unfiltered indices, which should matter most when the predicate is selective and the pre-filter match count is large.
Measure before committing: registers per thread and achieved occupancy for the fused retrieve kernel, peak memory, and end-to-end mixed join time against the current two-stage path, swept over predicate selectivity and match count.
Describe alternatives you've considered
Keep the two-stage path from #23012. It already resolved the occupancy problem, and its only cost is the intermediate allocation, which is negligible for unselective predicates.
Additional context
Given #23532, the row operators alone may dominate the budget, in which case fusing regresses occupancy regardless of cuco's removal and the current split stays.
Is your feature request related to a problem? Please describe.
Mixed joins previously ran fused AST and join kernels that suffered low occupancy from register pressure. Three components were monomorphized and fully inlined into one kernel body, keeping many values live at once: cuco's probing kernels, the row operators, and the AST evaluator.
#23012 split that into
hash_joinfollowed byfilter_join_indices(#20385), so no single kernel carries all three. The join kernel keeps cuco and the row operators, the filter kernel carries only the AST evaluator. The cost is that the join now materializes the full unfiltered index pair before filtering it.Describe the solution you'd like
#23640 replaces cuco's templated kernels with a hand-rolled table and four purpose-built kernels, removing one source from the join side. A re-fused kernel would therefore carry the row operators and the AST evaluator, but not cuco. Evaluate whether that pair fits in a register budget that still gives acceptable occupancy.
The win is not fewer passes; HashCSR is count, scan, fill, probe-count, scan, retrieve either way. It is that a fused retrieve never materializes the unfiltered indices, which should matter most when the predicate is selective and the pre-filter match count is large.
Measure before committing: registers per thread and achieved occupancy for the fused retrieve kernel, peak memory, and end-to-end mixed join time against the current two-stage path, swept over predicate selectivity and match count.
Describe alternatives you've considered
Keep the two-stage path from #23012. It already resolved the occupancy problem, and its only cost is the intermediate allocation, which is negligible for unselective predicates.
Additional context
Given #23532, the row operators alone may dominate the budget, in which case fusing regresses occupancy regardless of cuco's removal and the current split stays.