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
Update ClickBench benchmarks with DataFusion 52.0.0 #19826
Now that DataFusion 52.0.0 is released, It would be great to update ClickBench https://benchmark.clickhouse.com/ with the newest version and highlight and improvement. The current result is still of version 47.0.0
ClickBench is a benchmark heavy on filtering and aggregation that we have used as an optimization target for the last several releases.
I've updated both datafusion and datafusion-partitioned for four types of instances, PR ClickHouse/ClickBench#749.
For 4xlarge instances, almost all cases are improved, but I observed some regression in small instances (2x or x), like q3 q4 q5 now needs 2~3 seconds to run (here).
I prefer to update those results as-is, as at least all cases can run on every instance (xlarge has swap space), and the current result is a bit outdated. What do you think? cc @alamb@Omega359
I am not familiar enough with clickbench to have an opinion on what 'update the results as-is' means. I believe @pmcgleenon was the last person to update the clickbench results, perhaps he would be able to review?
There's a lot of data now with the 4 instance types, so I fired the before and after results into claude to see if we can get an overview of what's going on
I didn't see any null results in the c6a.xlarge this time, did we already make some improvements to run on a low memory system?
It turns out that I forgot to disable swap for queries... q18 (here) will be killed without swap memory 🥲
That's the danger of using swap. From what I understand swap is needed to compile datafusion-cli on the c6a.xlarge instance type which only has 8GB of RAM. I think we should remove c6a.xlarge from the Clickbench results. It can be added back in when the underlying issues get resolved
I think we should remove c6a.xlarge from the Clickbench results. It can be added back in when the underlying issues get resolved
+1. On the other hand, c6a.xlarge takes lots of time to run (compile + bench). For what I got this time, c6a.xlarge and c6a.2xlarge are reflecting a similar trend, keeping only c6a.2xlarge and above looks good to me.
I prefer to update those results as-is, as at least all cases can run on every instance (xlarge has swap space), and the current result is a bit outdated. What do you think? cc @alamb@Omega359
I agree we should update the results to reflect the current state of DataFusion. If the results are poor or regressed on the smaller instances, I think it is fine to post those results here (and then we can file tickets to improve the results in subsequent runs)
That's the danger of using swap. From what I understand swap is needed to compile datafusion-cli on the c6a.xlarge instance type which only has 8GB of RAM. I think we should remove c6a.xlarge from the Clickbench results. It can be added back in when the underlying issues get resolved
I personally think we should leave them in (it will make it clearer where we need to work to improve)
For 4xlarge instances, almost all cases are improved, but I observed some regression in small instances (2x or x), like q3 q4 q5 now needs 2~3 seconds to run (here).
@waynexia I suspect this is a result of using more memory somehow (and this swapping more).
What I think need to happen is that DataFusion's "out of core" story needs to improve (aka we shouldn't need swap space, we should be using the memory manager and spill mechanism).
However, when I last tried this I encountered issues running some of the queries
Should we publish the xlarge case number with swap enabled (which is the current number in ClickHouse/ClickBench#749), or rerun with swap disabled? I still kept the instance and compiled artifact, so I can get one soon. I'm wondering how it was done previously. This time it would be oom-killed on those queries, and the benchmark script is interrupted. Is it done manually?
Activity
waynexia commentedon Jan 15, 2026
I've updated both
datafusionanddatafusion-partitionedfor four types of instances, PR ClickHouse/ClickBench#749.For 4xlarge instances, almost all cases are improved, but I observed some regression in small instances (2x or x), like q3 q4 q5 now needs 2~3 seconds to run (here).
waynexia commentedon Jan 15, 2026
I prefer to update those results as-is, as at least all cases can run on every instance (xlarge has swap space), and the current result is a bit outdated. What do you think? cc @alamb @Omega359
Omega359 commentedon Jan 15, 2026
I am not familiar enough with clickbench to have an opinion on what 'update the results as-is' means. I believe @pmcgleenon was the last person to update the clickbench results, perhaps he would be able to review?
pmcgleenon commentedon Jan 15, 2026
@Omega359 it looks good to me. Nice work @waynexia !
There's a lot of data now with the 4 instance types, so I fired the before and after results into claude to see if we can get an overview of what's going on
I didn't see any null results in the c6a.xlarge this time, did we already make some improvements to run on a low memory system?
waynexia commentedon Jan 16, 2026
I'm not very sure if I disabled swap (for building datafusion) before running queries 🙈 re-running on xlarge to double check...
waynexia commentedon Jan 16, 2026
It turns out that I forgot to disable swap for queries... q18 (here) will be killed without swap memory 🥲
pmcgleenon commentedon Jan 16, 2026
That's the danger of using swap. From what I understand swap is needed to compile datafusion-cli on the
c6a.xlargeinstance type which only has 8GB of RAM. I think we should removec6a.xlargefrom the Clickbench results. It can be added back in when the underlying issues get resolvedAny thoughts @alamb @Omega359 @waynexia ?
waynexia commentedon Jan 16, 2026
+1. On the other hand,
c6a.xlargetakes lots of time to run (compile + bench). For what I got this time,c6a.xlargeandc6a.2xlargeare reflecting a similar trend, keeping onlyc6a.2xlargeand above looks good to me.alamb commentedon Jan 16, 2026
I agree we should update the results to reflect the current state of DataFusion. If the results are poor or regressed on the smaller instances, I think it is fine to post those results here (and then we can file tickets to improve the results in subsequent runs)
I personally think we should leave them in (it will make it clearer where we need to work to improve)
alamb commentedon Jan 16, 2026
@waynexia I suspect this is a result of using more memory somehow (and this swapping more).
What I think need to happen is that DataFusion's "out of core" story needs to improve (aka we shouldn't need swap space, we should be using the memory manager and spill mechanism).
However, when I last tried this I encountered issues running some of the queries
alamb commentedon Jan 16, 2026
So what I think we should do is
alamb commentedon Jan 16, 2026
Thank you all for all your work on this issue
waynexia commentedon Jan 16, 2026
Thank you, that makes sense to me.
Should we publish the xlarge case number with swap enabled (which is the current number in ClickHouse/ClickBench#749), or rerun with swap disabled? I still kept the instance and compiled artifact, so I can get one soon. I'm wondering how it was done previously. This time it would be oom-killed on those queries, and the benchmark script is interrupted. Is it done manually?
4 remaining items
waynexia commentedon Jan 22, 2026
I did a pair compare (xlarge, partitioned) using prebuilt binary from homebrew, the result looks good. Maybe we can use prebuilt in future runs.
waynexia commentedon Jan 23, 2026
Benchmark script is updated to use a prebuilt binary. ClickHouse/ClickBench#749 looks ready for review. What do you think about it @alamb @Omega359 @pmcgleenon
pmcgleenon commentedon Jan 23, 2026
Looks great @waynexia 🚀
Omega359 commentedon Jan 23, 2026
Just need to update the title for the PR and I think you're good to go
alamb commentedon Feb 27, 2026
Looks like we have merged ClickHouse/ClickBench#749 so let's close this one as done
Thanks @waynexia and @Omega359 and @pmcgleenon
alamb commentedon Feb 27, 2026
alamb commentedon Feb 27, 2026
FWIW I am starting to take a look at the results from this run here:
alamb commentedon Feb 27, 2026
Actually, it now seems like this PR was reverted
alamb commentedon Feb 28, 2026
I made an alternate proposal here
alamb commentedon Mar 6, 2026
I have a new PR to update to 52
alamb commentedon Mar 6, 2026
A sneak peek at the results
New results (1.45 away from the 🦆 )

Current results (1.61 away from the 🦆 ):

alamb commentedon Mar 9, 2026
ClickHouse/ClickBench#810 is merged and our results are live:
https://benchmark.clickhouse.com/#system=+curp|ti%20rud|kBP%20t&type=-&machine=+ca4e&cluster_size=-&opensource=-&hardware=+c&tuned=+n&metric=combined&queries=-