Optimize skewed intersect lists - #828
Conversation
|
Looks good. Some alternative designs if someone were to revisit: Planner-level fix ("pick HJ under skew") — more general in principle, but skew here is per-chunk runtime state (which probe tuple meets which 2048-chunk), invisible to plan-time cardinality estimates. The existing TODO in cost_model.cpp shows this is known-hard. Not actionable now. Runtime-adaptive escalation (start scalar; switch to galloping after N consecutive right-advances) — arguably more maintainable. SIMD/shuffle techniques — premature at 2048-element scale; nodeID_t is 16 bytes so it would also require a repack after the homogeneity check. |
|
Minor: LBUG_API on both functions exports processor internals into the shared ABI purely so a test can reach them. Since the kernels are tiny and called from one hot site, consider a header-only implementation in src/include (inlining also helps here — the call is inside the vector-at-a-time hot loop), which removes the export and the new .cpp entirely. Minor, but it simplifies the file layout the PR adds. Also could you run a cypher query that shows the benefit vs micro benchmark? |
adsharma
left a comment
There was a problem hiding this comment.
Requesting changes for the LBUG_API and potential refactoring into a header only.
Ladybug currently intersects two sorted adjacency lists using a scalar merge. When one list is much smaller than the other, this can scan most of the larger list one element at a time.
This PR adds a galloping-search fast path for skewed intersections. It jumps through the larger list exponentially and then uses binary search to find each value from the smaller list.
Galloping is selected automatically when:
Small, balanced, and mixed-table lists continue using the original scalar merge.
Isolated kernel performance
These numbers measure only list copying and intersection, not complete query execution.