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
{{ message }}
Repository navigation
Optimize semi, anti-joins to avoid dynamic dispatch for comparison #22877
Is your feature request related to a problem or challenge?
The RightSemi/RightAnti existence probe code path (#22828) verifies each candidate build/probe pair via JoinKeyComparator, whose arrow DynComparator is a boxed closure — an indirect call per candidate pair, which also blocks inlining.
We could instead specialize for joins on primitive types and do the type lookup only once per chunk.
Sorry for the confusion -- this was actually an issue I created to track a self-TODO while working on the existence probe implementation for semijoins. My initial implementation did a scalar equality comparison as part of the hash chain walk, which is what lead to per-element dynamic dispatch. The revised version does vectorized equality over a chunk of candidate matches, which avoids the per-element dynamic dispatch. So we're good here.
Activity
neilconway commentedon Jun 10, 2026
take
alamb commentedon Jun 10, 2026
This will make a big improvement. It would be great to find some way to reuse the join key key comparisons across join operators
mbutrovich commentedon Jun 10, 2026
Another "I did this already in SMJ" post: #21484 :)
Looking forward to seeing this in HJ, but #21484 should give an idea of performance win from this change.
neilconway commentedon Jun 11, 2026
Sorry for the confusion -- this was actually an issue I created to track a self-TODO while working on the existence probe implementation for semijoins. My initial implementation did a scalar equality comparison as part of the hash chain walk, which is what lead to per-element dynamic dispatch. The revised version does vectorized equality over a chunk of candidate matches, which avoids the per-element dynamic dispatch. So we're good here.