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
[EPIC] A collection of items to improve CASE performance #18075
Is your feature request related to a problem or challenge?
@pepijnve and @chenkovsky has been working on a series of improvements to improve the performance of evaluating CASE expressions performance that I think should be highlighted / made more visible, so I am making a ticket to collect the work
Copying this over from an arrow-rs discord discussion.
Perhaps we can implement case when more efficiently using interleave. The current implementation strategy builds up a result one branch at a time as in this diagram (I made some mistakes in the labels, but I think the idea is clear enough).
Diagram
What if instead of merging after every branch we keep the partial results separate and instead update an index Vec<(usize,usize)> as we go. To be able to do that efficiently, we augment the record batch with a "row number" array that gets filtered along with the record batch itself. That gives us the offsets in the index vec to update. When evaluation is complete everything gets bundled up into the final result array with a single interleave operation.
Activity
Short circuit complex case evaluation modes as soon as possible (#17898)
pepijnve commentedon Oct 20, 2025
Copying this over from an
arrow-rsdiscord discussion.Perhaps we can implement case when more efficiently using interleave. The current implementation strategy builds up a result one branch at a time as in this diagram (I made some mistakes in the labels, but I think the idea is clear enough).
Diagram
What if instead of merging after every branch we keep the partial results separate and instead update an index
Vec<(usize,usize)>as we go. To be able to do that efficiently, we augment the record batch with a "row number" array that gets filtered along with the record batch itself. That gives us the offsets in the index vec to update. When evaluation is complete everything gets bundled up into the final result array with a single interleave operation.Diagram
rluvaton commentedon Oct 20, 2025
I improved
zipin arrow for scalars by a lot:Currently waiting on review for the dependent PRs
repeat_slice_n_timestoMutableBufferarrow-rs#8658rluvaton commentedon Oct 21, 2025
Added another massive case when improvement when the pattern is map like (
when "aa" then 1 ...)PRs:
CASE WHEN#18203 - benchmarkit is 99% faster which means that you won't even notice that there is case when 😄
pepijnve commentedon Oct 23, 2025
@alamb could you add #18152 to the description list please?
Optimize merging of partial case expression results (#18152)
pepijnve commentedon Oct 28, 2025
@rluvaton if you're up for it, next one is ready to go #18329
Project record batches to avoid filtering unused columns in `CASE` ev…
Short circuit complex case evaluation modes as soon as possible (apac…
Optimize merging of partial case expression results (apache#18152)
Project record batches to avoid filtering unused columns in `CASE` ev…
Avoid scatter operation in `ExpressionOrExpression` case evaluation m…
Optimize merging of partial case expression results (apache#18152)
Project record batches to avoid filtering unused columns in `CASE` ev…
Avoid scatter operation in `ExpressionOrExpression` case evaluation m…
alamb commentedon Nov 19, 2025
I am going to claim this particular EPIC is done for reporting purposes (though I realize we still gave #18183 outstanding)
Short circuit complex case evaluation modes as soon as possible (apac…
perf: optimize CASE WHEN lookup table (2.5-22.5 times faster) (#18183)
Short circuit complex case evaluation modes as soon as possible (apac…
Optimize merging of partial case expression results (apache#18152)
Project record batches to avoid filtering unused columns in `CASE` ev…