You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@datafusion.apache.org by "jayzhan211 (via GitHub)" <gi...@apache.org> on 2026/09/21 14:26:36 UTC
[PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
jayzhan211 opened a new pull request, #25567:
URL: https://github.com/apache/datafusion/pull/25567
## Which issue does this PR close?
- Part of #20773 and #24704. Does not close them.
Draft, opened to share measurements and get feedback on the direction. The option is off by default, so nothing changes unless it is set.
## Rationale for this change
A hash aggregation with millions of groups per partition spends most of its time finding group ids: 69-97% of aggregate compute on ClickBench Q15-18 / Q31-35. The hash table and the group values no longer fit the CPU caches, and once several such tables of hundreds of MB compete (one per partition) the cost per row falls off a cliff (Q18: 42-51 ns per row up to 1M groups per partition, 530 ns at 4-8M).
This PR lets a final aggregation stop growing one table: past a threshold it moves its state and all further input into 64 hash buckets and aggregates the buckets one after another with a small, reused table. Buckets are emitted, released, compacted, spilled and split again independently.
Measured on an Apple M4 Pro, 12 partitions, `hash_aggregate_bucket_threshold = 262144`, time relative to `main` (interleaved runs, medians):
| query | time | peak RSS |
|---|---|---|
| ClickBench Q32 | 0.34x | 0.61x |
| ClickBench Q18 | 0.54x | 0.73x |
| TPC-H SF10 `GROUP BY l_orderkey, l_linenumber` | 0.62x | 0.40x |
| ClickBench Q15 | 0.77x | 0.53x |
| nested aggregation over lineitem (`SinglePartitioned`) | 0.80x | 0.47x |
| ClickBench Q35 / Q31 | 0.85x / 0.86x | 0.70x / 0.58x |
| ClickBench, all 43 queries | ~0.75x | |
| TPC-H SF10, all 22 queries | 1.01x | |
Known costs, which is why this is a draft and off by default:
| case | time |
|---|---|
| ClickBench Q13 / Q14 / Q12 (0.5-1M string-keyed groups per partition) | 1.07x / 1.06x / 1.03x |
| `GROUP BY l_partkey, l_suppkey` (input repeats its groups 7x) | 0.86x, but 1.48x peak RSS |
Where the remaining loss comes from (per final input row): Q14 costs 79-85 ns with one table and 91-99 ns bucketed, of which 42-46 ns is moving the row into its bucket (hash, gather, copy) and 49-54 ns the aggregation itself; Q31 goes from 85 ns to 24.5 + 19.5 ns. Moving rows is 35-55% of the bucketed aggregation everywhere, and `RepartitionExec` has already hashed, gathered and copied every one of these rows once. A trigger cannot fix that (a larger threshold, a self-timing trigger and holding input back were all measured and only move the loss); letting the repartition produce the buckets would remove it. I am prototyping that separately and will report on #20773.
## What changes are included in this PR?
One commit per step:
1. `datafusion.execution.hash_aggregate_bucket_threshold` (groups, default 0 = off) and the bucketed final aggregation: `aggregates/final_buckets.rs` (routing by hash with one gather per batch, per-bucket compaction, per-bucket spill through `SpillManager`) and the bucket output in `FinalHashAggregateStream`. State with nested types is excluded; a soft group limit disables it.
2. A partial aggregation table that reaches the threshold is flushed downstream while its groups do not recur (about 1024 sampled group hashes per flush, kept for the last 64 flushes; flushing stops once more than 20% of a sample recurs).
3. One hash table is reused across the buckets, and buckets of unique groups are not compacted again.
4. `aggregates/bucketed_aggregation.rs` shares the bucket logic with the single-stage stream, which buckets when it runs on every partition (`SinglePartitioned`). A lone `Single` stream keeps its table: measured 6-25% slower with buckets, because every row is aggregated twice.
5. A final table whose input holds about one row per group moves into buckets at a quarter of the threshold, so that little work is repeated; buckets are still split again at the full threshold.
## What is the testing strategy for this PR?
- Unit tests in `aggregates/final_buckets.rs` and `aggregates/hash_stream.rs`: bucketed results equal the single table for the final, partial and single-stage streams; buckets split again; buckets spill under a memory limit; repeated groups are compacted; the partial flush stops when groups recur.
- `aggregate_bucketed.slt`: 14 queries (FILTER, ROLLUP, ordered `array_agg`, DISTINCT, nested aggregation) at 4 and 1 partitions, with the option off and at 100 groups, all sections identical, with `bucket_splits` / `table_flush_count` checked in `EXPLAIN ANALYZE`.
- With the default temporarily set to 100, the aggregate unit tests, `memory_limit` tests and the aggregate / group by / distinct sqllogictests pass. One tight-memory file (`ordered_aggregate_spill.slt`, limits of 500K-2M) failed once in a loaded parallel run and passed in 6 isolated runs; memory behaviour under such limits differs with a 100-group threshold. `aggregate_fuzz::streaming_aggregate_test` does not, as expected: it compares partial state rows one by one, and a flushing partial aggregation legitimately emits a group more than once. It would have to merge partial rows first if the default ever became non-zero.
- `cargo fmt`, workspace clippy and the extended test suite pass.
## Are there any user-facing changes?
A new experimental configuration option, `datafusion.execution.hash_aggregate_bucket_threshold`, off by default, documented in `configs.md` together with its known costs. New metrics on `AggregateExec`: `bucket_splits`, `bucket_compactions`, `table_flush_count`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "Rachelint (via GitHub)" <gi...@apache.org>.
Rachelint commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5883601349
# String group keys queries
It seems q33 and q34 in benchmark machine in #25724 . Seems it is harder to measure when bucket approach will get improvement in string cases(I also found q33 and q34 get improvement in my local, but no change in benchmark machine and my cloud machine...), and it always depends on the hardware...
# Data buffer reusing for stringview
I agree with `the coalescer's garbage-collection copy is not waste`.
Actually I have made simple experiment about directly reusing the data buffer in q33 and q34 in #23168 before, and found no obvious improvement in the benchmark machine(but seems in apple m4, q34 have improvement for buffer reusing?).
The root cause may be complex, but it seems we should just copy rather than reusing in most cases...
# Q11/Q12/Q14
I think we can check if we encounter `Poll::Pending` in `final aggr`, for understanding if the regression is caused by pipeline blocking?
It seems the same problem as q33 and q34, it is hard to measure will bucket approach can get improvement in such cases, and hard to decide when should we enable the bucket approach.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5763577582
<!-- semver-check-comment -->
Thank you for opening this pull request!
Reviewer note: [cargo-semver-checks](https://github.com/obi1kenobi/cargo-semver-checks) reported the current version number is not SemVer-compatible with the changes in this pull request (compared against the base branch).
<details>
<summary>Details</summary>
```
Cloning apache/main
Building datafusion-common v55.1.0 (current)
Built [ 34.816s] (current)
Parsing datafusion-common v55.1.0 (current)
Parsed [ 0.061s] (current)
Building datafusion-common v55.1.0 (baseline)
Built [ 33.193s] (baseline)
Parsing datafusion-common v55.1.0 (baseline)
Parsed [ 0.060s] (baseline)
Checking datafusion-common v55.1.0 -> v55.1.0 (no change; assume patch)
Checked [ 0.799s] 223 checks: 222 pass, 1 fail, 0 warn, 31 skip
--- failure constructible_struct_adds_field: struct exhaustively constructible through public API adds field ---
Description:
A pub struct that could be exhaustively constructed with a literal using only public API has a new pub field, breaking existing exhaustive literals.
ref: https://doc.rust-lang.org/reference/expressions/struct-expr.html
impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.50.0/src/lints/constructible_struct_adds_field.ron
Failed in:
field ExecutionOptions.hash_aggregate_bucket_threshold in /home/runner/work/datafusion/datafusion/datafusion/common/src/config.rs:894
Summary semver requires new major version: 1 major and 0 minor checks failed
Finished [ 70.261s] datafusion-common
Building datafusion-physical-plan v55.1.0 (current)
Built [ 38.574s] (current)
Parsing datafusion-physical-plan v55.1.0 (current)
Parsed [ 0.169s] (current)
Building datafusion-physical-plan v55.1.0 (baseline)
Built [ 38.956s] (baseline)
Parsing datafusion-physical-plan v55.1.0 (baseline)
Parsed [ 0.166s] (baseline)
Checking datafusion-physical-plan v55.1.0 -> v55.1.0 (no change; assume patch)
Checked [ 0.769s] 223 checks: 223 pass, 31 skip
Summary no semver update required
Finished [ 80.015s] datafusion-physical-plan
Building datafusion-sqllogictest v55.1.0 (current)
Built [ 100.971s] (current)
Parsing datafusion-sqllogictest v55.1.0 (current)
Parsed [ 0.024s] (current)
Building datafusion-sqllogictest v55.1.0 (baseline)
Built [ 100.939s] (baseline)
Parsing datafusion-sqllogictest v55.1.0 (baseline)
Parsed [ 0.023s] (baseline)
Checking datafusion-sqllogictest v55.1.0 -> v55.1.0 (no change; assume patch)
Checked [ 0.105s] 223 checks: 223 pass, 31 skip
Summary no semver update required
Finished [ 205.027s] datafusion-sqllogictest
```
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5762875618
π€ Benchmark completed (GKE) | [trigger](https://github.com/apache/datafusion/pull/25567#issuecomment-5762634475)
**Instance:** `c4a-highmem-16` (12 vCPU / 65 GiB)
Comparing agg-bucketed-final (d4c6299a9ede9575990d8de7935dd5310981b69e) to 6574a8c (merge-base) [diff](https://github.com/apache/datafusion/compare/6574a8c3b2c93ef9689a677c1cc1c0a4a844617f..d4c6299a9ede9575990d8de7935dd5310981b69e)
<details><summary>Run configuration</summary>
```yaml
run benchmark clickbench_partitioned
```
</details>
<details><summary>CPU Details (lscpu)</summary>
```
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: ARM
Model name: Neoverse-V2
Model: 1
Thread(s) per core: 1
Core(s) per cluster: 16
Socket(s): -
Cluster(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache: 1 MiB (16 instances)
L1i cache: 1 MiB (16 instances)
L2 cache: 32 MiB (16 instances)
L3 cache: 80 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerability Gather data sampling: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; CSV2, BHB
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
```
</details>
<details><summary>Details</summary>
<p>
```
Comparing HEAD and agg-bucketed-final
--------------------
Benchmark clickbench_partitioned.json
--------------------
βββββββββββββ³βββββββββββββ³βββββββββββββββββββββ³ββββββββββββ
β Query β HEAD β agg-bucketed-final β Change β
β‘ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ©
β QQuery 0 β 1.25 ms β 1.25 ms β no change β
β QQuery 1 β 11.80 ms β 11.77 ms β no change β
β QQuery 2 β 36.73 ms β 36.65 ms β no change β
β QQuery 3 β 31.34 ms β 31.13 ms β no change β
β QQuery 4 β 236.65 ms β 232.08 ms β no change β
β QQuery 5 β 273.89 ms β 268.90 ms β no change β
β QQuery 6 β 1.30 ms β 1.34 ms β no change β
β QQuery 7 β 13.10 ms β 13.22 ms β no change β
β QQuery 8 β 325.60 ms β 327.84 ms β no change β
β QQuery 9 β 461.09 ms β 460.17 ms β no change β
β QQuery 10 β 64.86 ms β 64.03 ms β no change β
β QQuery 11 β 76.59 ms β 74.03 ms β no change β
β QQuery 12 β 262.58 ms β 256.42 ms β no change β
β QQuery 13 β 363.25 ms β 361.47 ms β no change β
β QQuery 14 β 275.23 ms β 277.07 ms β no change β
β QQuery 15 β 279.04 ms β 282.14 ms β no change β
β QQuery 16 β 613.87 ms β 617.38 ms β no change β
β QQuery 17 β 622.59 ms β 622.64 ms β no change β
β QQuery 18 β 1261.20 ms β 1275.19 ms β no change β
β QQuery 19 β 27.19 ms β 27.26 ms β no change β
β QQuery 20 β 512.65 ms β 517.19 ms β no change β
β QQuery 21 β 508.21 ms β 505.75 ms β no change β
β QQuery 22 β 979.33 ms β 973.45 ms β no change β
β QQuery 23 β 3054.95 ms β 3012.20 ms β no change β
β QQuery 24 β 40.11 ms β 40.98 ms β no change β
β QQuery 25 β 105.05 ms β 104.34 ms β no change β
β QQuery 26 β 40.60 ms β 40.77 ms β no change β
β QQuery 27 β 503.57 ms β 510.24 ms β no change β
β QQuery 28 β 2933.31 ms β 2850.67 ms β no change β
β QQuery 29 β 41.22 ms β 41.57 ms β no change β
β QQuery 30 β 305.33 ms β 304.90 ms β no change β
β QQuery 31 β 279.29 ms β 274.02 ms β no change β
β QQuery 32 β 926.21 ms β 951.96 ms β no change β
β QQuery 33 β 1445.97 ms β 1426.01 ms β no change β
β QQuery 34 β 1480.69 ms β 1465.89 ms β no change β
β QQuery 35 β 291.82 ms β 286.93 ms β no change β
β QQuery 36 β 66.19 ms β 66.08 ms β no change β
β QQuery 37 β 35.23 ms β 34.50 ms β no change β
β QQuery 38 β 41.02 ms β 42.52 ms β no change β
β QQuery 39 β 146.94 ms β 145.42 ms β no change β
β QQuery 40 β 14.22 ms β 14.23 ms β no change β
β QQuery 41 β 13.75 ms β 13.39 ms β no change β
β QQuery 42 β 13.29 ms β 12.90 ms β no change β
βββββββββββββ΄βββββββββββββ΄βββββββββββββββββββββ΄ββββββββββββ
βββββββββββββββββββββββββββββββββββββ³βββββββββββββ
β Benchmark Summary β β
β‘βββββββββββββββββββββββββββββββββββββββββββββββββ©
β Total Time (HEAD) β 19018.09ms β
β Total Time (agg-bucketed-final) β 18877.91ms β
β Average Time (HEAD) β 442.28ms β
β Average Time (agg-bucketed-final) β 439.02ms β
β Queries Faster β 0 β
β Queries Slower β 0 β
β Queries with No Change β 43 β
β Queries with Failure β 0 β
βββββββββββββββββββββββββββββββββββββ΄βββββββββββββ
Distribution per query (min / mean Β±stddev / max):
Comparing HEAD and agg-bucketed-final
--------------------
Benchmark clickbench_partitioned.json
--------------------
βββββββββββββ³ββββββββββββββββββββββββββββββββββββββββ³ββββββββββββββββββββββββββββββββββββββββ³ββββββββββββββββ
β Query β HEAD β agg-bucketed-final β Change β
β‘ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ©
β QQuery 0 β 1.25 / 4.03 Β±5.49 / 15.01 ms β 1.25 / 3.95 Β±5.34 / 14.63 ms β no change β
β QQuery 1 β 11.80 / 11.99 Β±0.15 / 12.27 ms β 11.77 / 11.91 Β±0.13 / 12.13 ms β no change β
β QQuery 2 β 36.73 / 37.76 Β±0.97 / 39.33 ms β 36.65 / 36.79 Β±0.15 / 37.08 ms β no change β
β QQuery 3 β 31.34 / 31.97 Β±0.69 / 33.32 ms β 31.13 / 31.30 Β±0.10 / 31.40 ms β no change β
β QQuery 4 β 236.65 / 238.67 Β±1.62 / 241.45 ms β 232.08 / 236.28 Β±3.53 / 242.57 ms β no change β
β QQuery 5 β 273.89 / 277.57 Β±5.49 / 288.41 ms β 268.90 / 271.85 Β±2.32 / 274.43 ms β no change β
β QQuery 6 β 1.30 / 1.45 Β±0.23 / 1.91 ms β 1.34 / 1.48 Β±0.22 / 1.92 ms β no change β
β QQuery 7 β 13.10 / 13.22 Β±0.12 / 13.43 ms β 13.22 / 13.43 Β±0.35 / 14.13 ms β no change β
β QQuery 8 β 325.60 / 330.35 Β±2.94 / 334.32 ms β 327.84 / 332.20 Β±2.29 / 334.37 ms β no change β
β QQuery 9 β 461.09 / 466.84 Β±4.69 / 473.46 ms β 460.17 / 474.59 Β±10.27 / 491.42 ms β no change β
β QQuery 10 β 64.86 / 66.45 Β±1.92 / 70.15 ms β 64.03 / 64.70 Β±1.06 / 66.82 ms β no change β
β QQuery 11 β 76.59 / 77.13 Β±0.52 / 77.83 ms β 74.03 / 74.95 Β±0.88 / 76.43 ms β no change β
β QQuery 12 β 262.58 / 266.31 Β±3.27 / 270.62 ms β 256.42 / 263.33 Β±5.26 / 271.55 ms β no change β
β QQuery 13 β 363.25 / 377.53 Β±14.48 / 405.37 ms β 361.47 / 383.16 Β±15.26 / 404.47 ms β no change β
β QQuery 14 β 275.23 / 279.65 Β±2.48 / 282.67 ms β 277.07 / 281.83 Β±3.88 / 288.48 ms β no change β
β QQuery 15 β 279.04 / 287.67 Β±5.64 / 295.47 ms β 282.14 / 288.27 Β±5.12 / 294.84 ms β no change β
β QQuery 16 β 613.87 / 627.98 Β±18.82 / 665.10 ms β 617.38 / 627.54 Β±14.45 / 655.98 ms β no change β
β QQuery 17 β 622.59 / 626.88 Β±3.05 / 631.55 ms β 622.64 / 634.06 Β±8.02 / 643.71 ms β no change β
β QQuery 18 β 1261.20 / 1274.25 Β±6.86 / 1280.83 ms β 1275.19 / 1298.89 Β±18.37 / 1322.00 ms β no change β
β QQuery 19 β 27.19 / 34.09 Β±12.88 / 59.85 ms β 27.26 / 33.88 Β±12.90 / 59.68 ms β no change β
β QQuery 20 β 512.65 / 527.73 Β±10.62 / 545.93 ms β 517.19 / 518.92 Β±2.41 / 523.59 ms β no change β
β QQuery 21 β 508.21 / 515.42 Β±5.46 / 522.57 ms β 505.75 / 512.83 Β±5.17 / 521.20 ms β no change β
β QQuery 22 β 979.33 / 987.95 Β±9.49 / 1004.67 ms β 973.45 / 980.29 Β±5.30 / 987.40 ms β no change β
β QQuery 23 β 3054.95 / 3081.30 Β±32.80 / 3144.52 ms β 3012.20 / 3052.39 Β±22.50 / 3070.69 ms β no change β
β QQuery 24 β 40.11 / 51.70 Β±15.76 / 81.42 ms β 40.98 / 51.29 Β±13.96 / 78.41 ms β no change β
β QQuery 25 β 105.05 / 108.48 Β±4.83 / 117.90 ms β 104.34 / 108.30 Β±4.87 / 117.81 ms β no change β
β QQuery 26 β 40.60 / 41.75 Β±1.36 / 44.30 ms β 40.77 / 41.04 Β±0.21 / 41.37 ms β no change β
β QQuery 27 β 503.57 / 514.03 Β±7.45 / 523.46 ms β 510.24 / 521.69 Β±9.98 / 540.01 ms β no change β
β QQuery 28 β 2933.31 / 2959.62 Β±24.55 / 2995.24 ms β 2850.67 / 2881.92 Β±21.10 / 2913.44 ms β no change β
β QQuery 29 β 41.22 / 47.82 Β±11.90 / 71.59 ms β 41.57 / 48.02 Β±9.25 / 66.20 ms β no change β
β QQuery 30 β 305.33 / 309.13 Β±2.19 / 311.99 ms β 304.90 / 310.91 Β±4.68 / 318.57 ms β no change β
β QQuery 31 β 279.29 / 288.31 Β±7.40 / 298.29 ms β 274.02 / 282.91 Β±10.75 / 302.99 ms β no change β
β QQuery 32 β 926.21 / 966.04 Β±35.39 / 1011.38 ms β 951.96 / 985.17 Β±21.70 / 1011.43 ms β no change β
β QQuery 33 β 1445.97 / 1468.47 Β±21.33 / 1505.08 ms β 1426.01 / 1458.78 Β±27.21 / 1503.08 ms β no change β
β QQuery 34 β 1480.69 / 1492.90 Β±10.67 / 1511.74 ms β 1465.89 / 1479.08 Β±17.82 / 1512.21 ms β no change β
β QQuery 35 β 291.82 / 303.21 Β±13.42 / 328.91 ms β 286.93 / 323.40 Β±33.82 / 370.62 ms β 1.07x slower β
β QQuery 36 β 66.19 / 68.23 Β±2.00 / 71.94 ms β 66.08 / 76.07 Β±11.12 / 95.98 ms β 1.11x slower β
β QQuery 37 β 35.23 / 40.06 Β±2.61 / 42.55 ms β 34.50 / 35.37 Β±0.65 / 36.33 ms β +1.13x faster β
β QQuery 38 β 41.02 / 43.92 Β±3.75 / 51.13 ms β 42.52 / 46.62 Β±6.43 / 59.32 ms β 1.06x slower β
β QQuery 39 β 146.94 / 153.79 Β±4.90 / 161.18 ms β 145.42 / 158.29 Β±13.67 / 184.55 ms β no change β
β QQuery 40 β 14.22 / 16.15 Β±2.37 / 20.75 ms β 14.23 / 14.42 Β±0.16 / 14.65 ms β +1.12x faster β
β QQuery 41 β 13.75 / 14.26 Β±0.33 / 14.65 ms β 13.39 / 15.04 Β±2.56 / 20.11 ms β 1.05x slower β
β QQuery 42 β 13.29 / 13.45 Β±0.21 / 13.86 ms β 12.90 / 15.69 Β±5.15 / 25.99 ms β 1.17x slower β
βββββββββββββ΄ββββββββββββββββββββββββββββββββββββββββ΄ββββββββββββββββββββββββββββββββββββββββ΄ββββββββββββββββ
βββββββββββββββββββββββββββββββββββββ³βββββββββββββ
β Benchmark Summary β β
β‘βββββββββββββββββββββββββββββββββββββββββββββββββ©
β Total Time (HEAD) β 19345.53ms β
β Total Time (agg-bucketed-final) β 19282.82ms β
β Average Time (HEAD) β 449.90ms β
β Average Time (agg-bucketed-final) β 448.44ms β
β Queries Faster β 2 β
β Queries Slower β 5 β
β Queries with No Change β 36 β
β Queries with Failure β 0 β
βββββββββββββββββββββββββββββββββββββ΄βββββββββββββ
```
</p>
</details>
<details><summary>Resource Usage</summary>
**clickbench_partitioned β base (merge-base)**
| Metric | Value |
|--------|-------|
| Wall time | 100.0s |
| Peak memory | 11.6 GiB |
| Avg memory | 4.5 GiB |
| CPU user | 991.3s |
| CPU sys | 67.6s |
| Peak spill | 0 B |
**clickbench_partitioned β branch**
| Metric | Value |
|--------|-------|
| Wall time | 100.0s |
| Peak memory | 10.7 GiB |
| Avg memory | 4.2 GiB |
| CPU user | 986.1s |
| CPU sys | 70.0s |
| Peak spill | 0 B |
</details>
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5770497488
Hi @Rachelint, your benchmark configuration could not be parsed (https://github.com/apache/datafusion/pull/25567#issuecomment-5770497307).
**Error:** `invalid configuration: unknown field `DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD`, expected one of `env`, `baseline`, `changed` at line 3 column 1`
Usage:
```
run benchmark <name> # run specific benchmark(s)
run benchmarks # run default suite
run benchmarks <name1> <name2> # run specific benchmarks
```
Any benchmark name is accepted: `bench.sh` suite names (e.g. `tpch`, `clickbench_partitioned`, `wide_schema`) and Criterion bench targets (e.g. `sql_planner`) are resolved automatically. A name that matches neither fails on the runner.
Per-side configuration (`run benchmark tpch` followed by):
```yaml
env:
# shared env is inherited by BOTH the build and the run, so build
# flags go here. Builds default to no debuginfo for speed; opt back
# in for hung-job gdb dumps and cap jobs to stay within memory:
CARGO_PROFILE_RELEASE_DEBUG: "1"
CARGO_BUILD_JOBS: "1"
baseline:
ref: v45.0.0
env:
# per-side env only reaches the benchmark run, not the build
DATAFUSION_RUNTIME_MEMORY_LIMIT: 1G
changed:
ref: v46.0.0
env:
DATAFUSION_RUNTIME_MEMORY_LIMIT: 2G
```
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5770705807
π€ Benchmark completed (GKE) | [trigger](https://github.com/apache/datafusion/pull/25567#issuecomment-5770623516)
**Instance:** `c4a-highmem-16` (12 vCPU / 65 GiB)
Comparing agg-bucketed-final (d4c6299a9ede9575990d8de7935dd5310981b69e) to 6574a8c (merge-base) [diff](https://github.com/apache/datafusion/compare/6574a8c3b2c93ef9689a677c1cc1c0a4a844617f..d4c6299a9ede9575990d8de7935dd5310981b69e)
<details><summary>Run configuration</summary>
```yaml
run benchmark clickbench_partitioned
changed:
env:
DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"
```
</details>
<details><summary>CPU Details (lscpu)</summary>
```
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: ARM
Model name: Neoverse-V2
Model: 1
Thread(s) per core: 1
Core(s) per cluster: 16
Socket(s): -
Cluster(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache: 1 MiB (16 instances)
L1i cache: 1 MiB (16 instances)
L2 cache: 32 MiB (16 instances)
L3 cache: 80 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerability Gather data sampling: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; CSV2, BHB
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
```
</details>
<details><summary>Details</summary>
<p>
```
Comparing HEAD and agg-bucketed-final
--------------------
Benchmark clickbench_partitioned.json
--------------------
βββββββββββββ³βββββββββββββ³βββββββββββββββββββββ³ββββββββββββββββ
β Query β HEAD β agg-bucketed-final β Change β
β‘ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ©
β QQuery 0 β 1.36 ms β 1.27 ms β +1.07x faster β
β QQuery 1 β 12.39 ms β 11.84 ms β no change β
β QQuery 2 β 37.96 ms β 37.01 ms β no change β
β QQuery 3 β 33.14 ms β 32.22 ms β no change β
β QQuery 4 β 256.16 ms β 190.21 ms β +1.35x faster β
β QQuery 5 β 287.77 ms β 285.95 ms β no change β
β QQuery 6 β 1.33 ms β 1.35 ms β no change β
β QQuery 7 β 13.54 ms β 13.59 ms β no change β
β QQuery 8 β 365.96 ms β 301.23 ms β +1.21x faster β
β QQuery 9 β 527.24 ms β 522.65 ms β no change β
β QQuery 10 β 69.62 ms β 69.47 ms β no change β
β QQuery 11 β 79.68 ms β 80.31 ms β no change β
β QQuery 12 β 293.55 ms β 295.02 ms β no change β
β QQuery 13 β 400.05 ms β 400.67 ms β no change β
β QQuery 14 β 306.49 ms β 310.58 ms β no change β
β QQuery 15 β 334.09 ms β 244.44 ms β +1.37x faster β
β QQuery 16 β 685.82 ms β 734.17 ms β 1.07x slower β
β QQuery 17 β 687.59 ms β 640.91 ms β +1.07x faster β
β QQuery 18 β 1429.75 ms β 1238.31 ms β +1.15x faster β
β QQuery 19 β 29.06 ms β 29.18 ms β no change β
β QQuery 20 β 529.66 ms β 538.23 ms β no change β
β QQuery 21 β 520.43 ms β 530.17 ms β no change β
β QQuery 22 β 1005.49 ms β 1050.47 ms β no change β
β QQuery 23 β 3256.35 ms β 3342.26 ms β no change β
β QQuery 24 β 41.86 ms β 41.63 ms β no change β
β QQuery 25 β 108.73 ms β 107.56 ms β no change β
β QQuery 26 β 43.15 ms β 42.48 ms β no change β
β QQuery 27 β 528.14 ms β 531.44 ms β no change β
β QQuery 28 β 2989.46 ms β 2976.58 ms β no change β
β QQuery 29 β 42.59 ms β 42.75 ms β no change β
β QQuery 30 β 330.69 ms β 296.71 ms β +1.11x faster β
β QQuery 31 β 301.33 ms β 257.51 ms β +1.17x faster β
β QQuery 32 β 1054.47 ms β 774.59 ms β +1.36x faster β
β QQuery 33 β 1569.88 ms β 1584.76 ms β no change β
β QQuery 34 β 1589.02 ms β 1637.91 ms β no change β
β QQuery 35 β 361.15 ms β 247.61 ms β +1.46x faster β
β QQuery 36 β 74.68 ms β 70.52 ms β +1.06x faster β
β QQuery 37 β 39.72 ms β 37.01 ms β +1.07x faster β
β QQuery 38 β 46.40 ms β 41.09 ms β +1.13x faster β
β QQuery 39 β 178.64 ms β 147.09 ms β +1.21x faster β
β QQuery 40 β 17.24 ms β 15.33 ms β +1.12x faster β
β QQuery 41 β 16.12 ms β 14.49 ms β +1.11x faster β
β QQuery 42 β 15.34 ms β 14.18 ms β +1.08x faster β
βββββββββββββ΄βββββββββββββ΄βββββββββββββββββββββ΄ββββββββββββββββ
βββββββββββββββββββββββββββββββββββββ³βββββββββββββ
β Benchmark Summary β β
β‘βββββββββββββββββββββββββββββββββββββββββββββββββ©
β Total Time (HEAD) β 20513.10ms β
β Total Time (agg-bucketed-final) β 19782.78ms β
β Average Time (HEAD) β 477.05ms β
β Average Time (agg-bucketed-final) β 460.06ms β
β Queries Faster β 17 β
β Queries Slower β 1 β
β Queries with No Change β 25 β
β Queries with Failure β 0 β
βββββββββββββββββββββββββββββββββββββ΄βββββββββββββ
Distribution per query (min / mean Β±stddev / max):
Comparing HEAD and agg-bucketed-final
--------------------
Benchmark clickbench_partitioned.json
--------------------
βββββββββββββ³ββββββββββββββββββββββββββββββββββββββββ³ββββββββββββββββββββββββββββββββββββββββ³ββββββββββββββββ
β Query β HEAD β agg-bucketed-final β Change β
β‘ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ©
β QQuery 0 β 1.36 / 4.49 Β±5.97 / 16.43 ms β 1.27 / 4.22 Β±5.74 / 15.71 ms β +1.06x faster β
β QQuery 1 β 12.39 / 12.63 Β±0.19 / 12.95 ms β 11.84 / 12.22 Β±0.26 / 12.64 ms β no change β
β QQuery 2 β 37.96 / 38.11 Β±0.13 / 38.29 ms β 37.01 / 37.62 Β±0.35 / 38.05 ms β no change β
β QQuery 3 β 33.14 / 34.40 Β±1.21 / 36.33 ms β 32.22 / 32.79 Β±0.38 / 33.29 ms β no change β
β QQuery 4 β 256.16 / 262.70 Β±4.53 / 269.98 ms β 190.21 / 192.42 Β±1.66 / 194.47 ms β +1.37x faster β
β QQuery 5 β 287.77 / 297.77 Β±6.21 / 304.83 ms β 285.95 / 293.52 Β±5.32 / 300.77 ms β no change β
β QQuery 6 β 1.33 / 1.49 Β±0.24 / 1.96 ms β 1.35 / 1.52 Β±0.24 / 1.99 ms β no change β
β QQuery 7 β 13.54 / 13.88 Β±0.19 / 14.08 ms β 13.59 / 13.66 Β±0.04 / 13.71 ms β no change β
β QQuery 8 β 365.96 / 384.40 Β±9.31 / 391.25 ms β 301.23 / 311.16 Β±8.95 / 325.39 ms β +1.24x faster β
β QQuery 9 β 527.24 / 538.66 Β±9.63 / 553.69 ms β 522.65 / 538.35 Β±13.66 / 558.55 ms β no change β
β QQuery 10 β 69.62 / 71.90 Β±3.15 / 78.02 ms β 69.47 / 75.67 Β±11.36 / 98.38 ms β 1.05x slower β
β QQuery 11 β 79.68 / 81.25 Β±1.54 / 83.68 ms β 80.31 / 81.22 Β±0.78 / 82.43 ms β no change β
β QQuery 12 β 293.55 / 299.33 Β±6.05 / 307.83 ms β 295.02 / 306.18 Β±12.61 / 330.73 ms β no change β
β QQuery 13 β 400.05 / 423.60 Β±13.43 / 440.73 ms β 400.67 / 423.49 Β±12.74 / 436.14 ms β no change β
β QQuery 14 β 306.49 / 318.11 Β±9.93 / 336.59 ms β 310.58 / 339.40 Β±26.79 / 388.11 ms β 1.07x slower β
β QQuery 15 β 334.09 / 343.17 Β±4.76 / 347.03 ms β 244.44 / 245.60 Β±1.15 / 247.64 ms β +1.40x faster β
β QQuery 16 β 685.82 / 710.92 Β±16.52 / 728.09 ms β 734.17 / 755.31 Β±20.46 / 780.88 ms β 1.06x slower β
β QQuery 17 β 687.59 / 714.22 Β±22.00 / 746.63 ms β 640.91 / 660.59 Β±17.78 / 688.63 ms β +1.08x faster β
β QQuery 18 β 1429.75 / 1470.29 Β±25.55 / 1499.53 ms β 1238.31 / 1317.36 Β±66.23 / 1425.02 ms β +1.12x faster β
β QQuery 19 β 29.06 / 38.60 Β±11.87 / 59.79 ms β 29.18 / 89.16 Β±77.28 / 219.92 ms β 2.31x slower β
β QQuery 20 β 529.66 / 536.97 Β±10.85 / 558.45 ms β 538.23 / 548.94 Β±6.87 / 559.26 ms β no change β
β QQuery 21 β 520.43 / 526.72 Β±3.65 / 530.08 ms β 530.17 / 541.71 Β±8.24 / 553.50 ms β no change β
β QQuery 22 β 1005.49 / 1026.53 Β±11.95 / 1042.54 ms β 1050.47 / 1072.57 Β±20.38 / 1098.78 ms β no change β
β QQuery 23 β 3256.35 / 3380.79 Β±89.45 / 3478.08 ms β 3342.26 / 3379.49 Β±23.16 / 3402.91 ms β no change β
β QQuery 24 β 41.86 / 44.19 Β±4.43 / 53.06 ms β 41.63 / 49.37 Β±12.44 / 74.14 ms β 1.12x slower β
β QQuery 25 β 108.73 / 117.43 Β±7.82 / 130.41 ms β 107.56 / 110.38 Β±2.66 / 113.77 ms β +1.06x faster β
β QQuery 26 β 43.15 / 43.98 Β±0.86 / 45.57 ms β 42.48 / 46.95 Β±5.23 / 56.83 ms β 1.07x slower β
β QQuery 27 β 528.14 / 544.81 Β±10.26 / 556.53 ms β 531.44 / 543.09 Β±10.40 / 556.71 ms β no change β
β QQuery 28 β 2989.46 / 3055.55 Β±41.29 / 3116.91 ms β 2976.58 / 3033.43 Β±45.07 / 3113.84 ms β no change β
β QQuery 29 β 42.59 / 49.42 Β±6.91 / 59.00 ms β 42.75 / 52.01 Β±13.19 / 77.26 ms β 1.05x slower β
β QQuery 30 β 330.69 / 340.80 Β±9.10 / 357.20 ms β 296.71 / 308.41 Β±13.05 / 331.62 ms β +1.11x faster β
β QQuery 31 β 301.33 / 311.66 Β±12.66 / 335.78 ms β 257.51 / 262.06 Β±4.88 / 270.12 ms β +1.19x faster β
β QQuery 32 β 1054.47 / 1073.55 Β±16.36 / 1099.79 ms β 774.59 / 883.40 Β±127.50 / 1131.59 ms β +1.22x faster β
β QQuery 33 β 1569.88 / 1616.50 Β±70.68 / 1757.36 ms β 1584.76 / 1673.30 Β±87.21 / 1825.41 ms β no change β
β QQuery 34 β 1589.02 / 1668.18 Β±65.97 / 1756.72 ms β 1637.91 / 1758.02 Β±76.04 / 1874.21 ms β 1.05x slower β
β QQuery 35 β 361.15 / 395.29 Β±36.74 / 458.28 ms β 247.61 / 325.66 Β±110.93 / 533.18 ms β +1.21x faster β
β QQuery 36 β 74.68 / 76.83 Β±2.30 / 81.07 ms β 70.52 / 76.66 Β±5.05 / 84.49 ms β no change β
β QQuery 37 β 39.72 / 45.70 Β±7.41 / 58.39 ms β 37.01 / 38.48 Β±1.83 / 42.01 ms β +1.19x faster β
β QQuery 38 β 46.40 / 51.07 Β±3.60 / 54.67 ms β 41.09 / 43.29 Β±1.56 / 45.37 ms β +1.18x faster β
β QQuery 39 β 178.64 / 188.65 Β±6.47 / 198.01 ms β 147.09 / 152.58 Β±3.13 / 156.64 ms β +1.24x faster β
β QQuery 40 β 17.24 / 20.91 Β±4.70 / 29.79 ms β 15.33 / 17.32 Β±2.67 / 22.56 ms β +1.21x faster β
β QQuery 41 β 16.12 / 19.43 Β±6.37 / 32.17 ms β 14.49 / 15.20 Β±0.62 / 16.33 ms β +1.28x faster β
β QQuery 42 β 15.34 / 16.49 Β±1.83 / 20.13 ms β 14.18 / 14.35 Β±0.19 / 14.63 ms β +1.15x faster β
βββββββββββββ΄ββββββββββββββββββββββββββββββββββββββββ΄ββββββββββββββββββββββββββββββββββββββββ΄ββββββββββββββββ
βββββββββββββββββββββββββββββββββββββ³βββββββββββββ
β Benchmark Summary β β
β‘βββββββββββββββββββββββββββββββββββββββββββββββββ©
β Total Time (HEAD) β 21211.35ms β
β Total Time (agg-bucketed-final) β 20678.14ms β
β Average Time (HEAD) β 493.29ms β
β Average Time (agg-bucketed-final) β 480.89ms β
β Queries Faster β 17 β
β Queries Slower β 8 β
β Queries with No Change β 18 β
β Queries with Failure β 0 β
βββββββββββββββββββββββββββββββββββββ΄βββββββββββββ
```
</p>
</details>
<details><summary>Resource Usage</summary>
**clickbench_partitioned β base (merge-base)**
| Metric | Value |
|--------|-------|
| Wall time | 110.0s |
| Peak memory | 10.6 GiB |
| Avg memory | 4.3 GiB |
| CPU user | 1077.7s |
| CPU sys | 84.5s |
| Peak spill | 0 B |
**clickbench_partitioned β branch**
| Metric | Value |
|--------|-------|
| Wall time | 105.0s |
| Peak memory | 9.7 GiB |
| Avg memory | 3.9 GiB |
| CPU user | 1005.5s |
| CPU sys | 92.5s |
| Peak spill | 0 B |
</details>
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "Rachelint (via GitHub)" <gi...@apache.org>.
Rachelint commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5762634475
run benchmarks clickbench_partitioned
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5770856795
π€ Benchmark completed (GKE) | [trigger](https://github.com/apache/datafusion/pull/25567#issuecomment-5770778035)
**Instance:** `c4a-highmem-16` (12 vCPU / 65 GiB)
Comparing agg-bucketed-final (d4c6299a9ede9575990d8de7935dd5310981b69e) to 6574a8c (merge-base) [diff](https://github.com/apache/datafusion/compare/6574a8c3b2c93ef9689a677c1cc1c0a4a844617f..d4c6299a9ede9575990d8de7935dd5310981b69e)
<details><summary>Run configuration</summary>
```yaml
run benchmark clickbench_partitioned
changed:
env:
DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"
```
</details>
<details><summary>CPU Details (lscpu)</summary>
```
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: ARM
Model name: Neoverse-V2
Model: 1
Thread(s) per core: 1
Core(s) per cluster: 16
Socket(s): -
Cluster(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache: 1 MiB (16 instances)
L1i cache: 1 MiB (16 instances)
L2 cache: 32 MiB (16 instances)
L3 cache: 80 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerability Gather data sampling: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; CSV2, BHB
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
```
</details>
<details><summary>Details</summary>
<p>
```
Comparing HEAD and agg-bucketed-final
--------------------
Benchmark clickbench_partitioned.json
--------------------
βββββββββββββ³βββββββββββββ³βββββββββββββββββββββ³ββββββββββββββββ
β Query β HEAD β agg-bucketed-final β Change β
β‘ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ©
β QQuery 0 β 1.28 ms β 1.22 ms β no change β
β QQuery 1 β 12.02 ms β 11.81 ms β no change β
β QQuery 2 β 37.20 ms β 36.83 ms β no change β
β QQuery 3 β 32.15 ms β 31.40 ms β no change β
β QQuery 4 β 249.54 ms β 188.98 ms β +1.32x faster β
β QQuery 5 β 283.60 ms β 279.81 ms β no change β
β QQuery 6 β 1.29 ms β 1.27 ms β no change β
β QQuery 7 β 13.54 ms β 13.22 ms β no change β
β QQuery 8 β 345.40 ms β 296.51 ms β +1.16x faster β
β QQuery 9 β 497.19 ms β 475.23 ms β no change β
β QQuery 10 β 67.36 ms β 67.15 ms β no change β
β QQuery 11 β 77.97 ms β 79.07 ms β no change β
β QQuery 12 β 286.27 ms β 272.02 ms β no change β
β QQuery 13 β 380.65 ms β 378.05 ms β no change β
β QQuery 14 β 295.74 ms β 293.74 ms β no change β
β QQuery 15 β 300.52 ms β 219.94 ms β +1.37x faster β
β QQuery 16 β 644.90 ms β 666.12 ms β no change β
β QQuery 17 β 644.54 ms β 578.51 ms β +1.11x faster β
β QQuery 18 β 1318.24 ms β 1197.63 ms β +1.10x faster β
β QQuery 19 β 27.97 ms β 27.71 ms β no change β
β QQuery 20 β 523.57 ms β 525.05 ms β no change β
β QQuery 21 β 516.25 ms β 512.56 ms β no change β
β QQuery 22 β 989.71 ms β 998.06 ms β no change β
β QQuery 23 β 3167.07 ms β 3078.10 ms β no change β
β QQuery 24 β 42.67 ms β 40.69 ms β no change β
β QQuery 25 β 108.06 ms β 105.18 ms β no change β
β QQuery 26 β 42.38 ms β 42.56 ms β no change β
β QQuery 27 β 521.97 ms β 511.85 ms β no change β
β QQuery 28 β 2988.57 ms β 2907.93 ms β no change β
β QQuery 29 β 42.56 ms β 41.64 ms β no change β
β QQuery 30 β 319.91 ms β 291.17 ms β +1.10x faster β
β QQuery 31 β 295.88 ms β 251.45 ms β +1.18x faster β
β QQuery 32 β 994.78 ms β 739.53 ms β +1.35x faster β
β QQuery 33 β 1499.71 ms β 1444.39 ms β no change β
β QQuery 34 β 1519.55 ms β 1474.66 ms β no change β
β QQuery 35 β 307.17 ms β 227.91 ms β +1.35x faster β
β QQuery 36 β 65.76 ms β 67.49 ms β no change β
β QQuery 37 β 35.68 ms β 35.67 ms β no change β
β QQuery 38 β 41.29 ms β 45.21 ms β 1.09x slower β
β QQuery 39 β 147.97 ms β 139.11 ms β +1.06x faster β
β QQuery 40 β 14.82 ms β 14.66 ms β no change β
β QQuery 41 β 14.06 ms β 14.01 ms β no change β
β QQuery 42 β 13.64 ms β 13.48 ms β no change β
βββββββββββββ΄βββββββββββββ΄βββββββββββββββββββββ΄ββββββββββββββββ
βββββββββββββββββββββββββββββββββββββ³βββββββββββββ
β Benchmark Summary β β
β‘βββββββββββββββββββββββββββββββββββββββββββββββββ©
β Total Time (HEAD) β 19730.42ms β
β Total Time (agg-bucketed-final) β 18638.58ms β
β Average Time (HEAD) β 458.85ms β
β Average Time (agg-bucketed-final) β 433.46ms β
β Queries Faster β 10 β
β Queries Slower β 1 β
β Queries with No Change β 32 β
β Queries with Failure β 0 β
βββββββββββββββββββββββββββββββββββββ΄βββββββββββββ
Distribution per query (min / mean Β±stddev / max):
Comparing HEAD and agg-bucketed-final
--------------------
Benchmark clickbench_partitioned.json
--------------------
βββββββββββββ³ββββββββββββββββββββββββββββββββββββββββ³ββββββββββββββββββββββββββββββββββββββββ³ββββββββββββββββ
β Query β HEAD β agg-bucketed-final β Change β
β‘ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ©
β QQuery 0 β 1.28 / 4.33 Β±5.87 / 16.07 ms β 1.22 / 4.10 Β±5.61 / 15.32 ms β +1.06x faster β
β QQuery 1 β 12.02 / 12.56 Β±0.30 / 12.83 ms β 11.81 / 12.08 Β±0.19 / 12.40 ms β no change β
β QQuery 2 β 37.20 / 37.42 Β±0.28 / 37.91 ms β 36.83 / 37.07 Β±0.21 / 37.44 ms β no change β
β QQuery 3 β 32.15 / 32.98 Β±1.12 / 35.13 ms β 31.40 / 31.63 Β±0.15 / 31.83 ms β no change β
β QQuery 4 β 249.54 / 254.64 Β±3.63 / 258.99 ms β 188.98 / 192.00 Β±2.94 / 196.37 ms β +1.33x faster β
β QQuery 5 β 283.60 / 287.18 Β±2.00 / 289.05 ms β 279.81 / 288.79 Β±6.93 / 301.01 ms β no change β
β QQuery 6 β 1.29 / 1.44 Β±0.24 / 1.91 ms β 1.27 / 1.42 Β±0.24 / 1.91 ms β no change β
β QQuery 7 β 13.54 / 14.08 Β±0.31 / 14.45 ms β 13.22 / 13.45 Β±0.14 / 13.60 ms β no change β
β QQuery 8 β 345.40 / 353.54 Β±5.73 / 363.07 ms β 296.51 / 303.74 Β±5.20 / 310.74 ms β +1.16x faster β
β QQuery 9 β 497.19 / 511.42 Β±11.62 / 530.16 ms β 475.23 / 486.98 Β±7.64 / 496.38 ms β no change β
β QQuery 10 β 67.36 / 69.09 Β±1.20 / 70.75 ms β 67.15 / 67.53 Β±0.44 / 68.40 ms β no change β
β QQuery 11 β 77.97 / 78.86 Β±1.18 / 80.95 ms β 79.07 / 82.82 Β±6.02 / 94.72 ms β 1.05x slower β
β QQuery 12 β 286.27 / 289.28 Β±3.10 / 295.23 ms β 272.02 / 280.29 Β±6.99 / 291.26 ms β no change β
β QQuery 13 β 380.65 / 397.07 Β±12.57 / 418.61 ms β 378.05 / 385.64 Β±4.69 / 390.19 ms β no change β
β QQuery 14 β 295.74 / 300.53 Β±4.32 / 307.92 ms β 293.74 / 301.52 Β±6.52 / 309.41 ms β no change β
β QQuery 15 β 300.52 / 307.07 Β±5.11 / 314.56 ms β 219.94 / 224.87 Β±5.10 / 233.28 ms β +1.37x faster β
β QQuery 16 β 644.90 / 651.06 Β±4.79 / 656.79 ms β 666.12 / 690.56 Β±17.39 / 717.77 ms β 1.06x slower β
β QQuery 17 β 644.54 / 657.92 Β±12.78 / 677.84 ms β 578.51 / 602.95 Β±13.12 / 614.57 ms β +1.09x faster β
β QQuery 18 β 1318.24 / 1337.40 Β±16.82 / 1364.88 ms β 1197.63 / 1249.62 Β±30.31 / 1283.40 ms β +1.07x faster β
β QQuery 19 β 27.97 / 30.47 Β±4.03 / 38.51 ms β 27.71 / 41.44 Β±27.04 / 95.51 ms β 1.36x slower β
β QQuery 20 β 523.57 / 544.57 Β±28.62 / 597.74 ms β 525.05 / 543.49 Β±24.13 / 590.20 ms β no change β
β QQuery 21 β 516.25 / 519.35 Β±3.50 / 525.95 ms β 512.56 / 524.85 Β±7.68 / 535.57 ms β no change β
β QQuery 22 β 989.71 / 1001.02 Β±7.75 / 1009.40 ms β 998.06 / 1022.72 Β±19.04 / 1052.54 ms β no change β
β QQuery 23 β 3167.07 / 3203.15 Β±28.28 / 3238.08 ms β 3078.10 / 3129.53 Β±29.48 / 3168.32 ms β no change β
β QQuery 24 β 42.67 / 44.90 Β±3.56 / 51.99 ms β 40.69 / 42.49 Β±1.53 / 45.33 ms β +1.06x faster β
β QQuery 25 β 108.06 / 113.54 Β±5.63 / 121.27 ms β 105.18 / 107.44 Β±4.07 / 115.57 ms β +1.06x faster β
β QQuery 26 β 42.38 / 43.59 Β±1.13 / 45.72 ms β 42.56 / 48.10 Β±7.42 / 61.85 ms β 1.10x slower β
β QQuery 27 β 521.97 / 527.16 Β±7.98 / 542.97 ms β 511.85 / 526.49 Β±8.06 / 535.21 ms β no change β
β QQuery 28 β 2988.57 / 3012.42 Β±19.03 / 3043.78 ms β 2907.93 / 2952.74 Β±35.00 / 3015.12 ms β no change β
β QQuery 29 β 42.56 / 49.66 Β±12.74 / 75.07 ms β 41.64 / 42.20 Β±0.55 / 43.25 ms β +1.18x faster β
β QQuery 30 β 319.91 / 329.24 Β±8.55 / 344.89 ms β 291.17 / 313.27 Β±32.27 / 375.94 ms β no change β
β QQuery 31 β 295.88 / 305.80 Β±9.11 / 319.75 ms β 251.45 / 258.27 Β±4.24 / 264.30 ms β +1.18x faster β
β QQuery 32 β 994.78 / 1019.77 Β±17.66 / 1037.84 ms β 739.53 / 748.98 Β±5.46 / 756.60 ms β +1.36x faster β
β QQuery 33 β 1499.71 / 1525.98 Β±23.35 / 1564.08 ms β 1444.39 / 1542.37 Β±83.97 / 1658.59 ms β no change β
β QQuery 34 β 1519.55 / 1543.88 Β±20.58 / 1576.56 ms β 1474.66 / 1502.14 Β±25.52 / 1548.81 ms β no change β
β QQuery 35 β 307.17 / 357.33 Β±78.56 / 513.83 ms β 227.91 / 259.35 Β±28.91 / 302.70 ms β +1.38x faster β
β QQuery 36 β 65.76 / 73.68 Β±7.39 / 86.29 ms β 67.49 / 73.24 Β±6.70 / 84.75 ms β no change β
β QQuery 37 β 35.68 / 40.15 Β±3.87 / 44.76 ms β 35.67 / 37.89 Β±3.13 / 43.96 ms β +1.06x faster β
β QQuery 38 β 41.29 / 44.71 Β±4.48 / 53.51 ms β 45.21 / 47.79 Β±1.99 / 50.46 ms β 1.07x slower β
β QQuery 39 β 147.97 / 157.92 Β±7.21 / 166.97 ms β 139.11 / 150.21 Β±8.40 / 158.79 ms β no change β
β QQuery 40 β 14.82 / 16.90 Β±3.18 / 23.14 ms β 14.66 / 16.65 Β±2.96 / 22.51 ms β no change β
β QQuery 41 β 14.06 / 14.26 Β±0.13 / 14.42 ms β 14.01 / 14.89 Β±1.27 / 17.35 ms β no change β
β QQuery 42 β 13.64 / 14.96 Β±2.18 / 19.30 ms β 13.48 / 14.99 Β±2.78 / 20.53 ms β no change β
βββββββββββββ΄ββββββββββββββββββββββββββββββββββββββββ΄ββββββββββββββββββββββββββββββββββββββββ΄ββββββββββββββββ
βββββββββββββββββββββββββββββββββββββ³βββββββββββββ
β Benchmark Summary β β
β‘βββββββββββββββββββββββββββββββββββββββββββββββββ©
β Total Time (HEAD) β 20132.28ms β
β Total Time (agg-bucketed-final) β 19218.58ms β
β Average Time (HEAD) β 468.19ms β
β Average Time (agg-bucketed-final) β 446.94ms β
β Queries Faster β 13 β
β Queries Slower β 5 β
β Queries with No Change β 25 β
β Queries with Failure β 0 β
βββββββββββββββββββββββββββββββββββββ΄βββββββββββββ
```
</p>
</details>
<details><summary>Resource Usage</summary>
**clickbench_partitioned β base (merge-base)**
| Metric | Value |
|--------|-------|
| Wall time | 105.0s |
| Peak memory | 10.3 GiB |
| Avg memory | 4.2 GiB |
| CPU user | 1029.5s |
| CPU sys | 71.6s |
| Peak spill | 0 B |
**clickbench_partitioned β branch**
| Metric | Value |
|--------|-------|
| Wall time | 100.0s |
| Peak memory | 7.9 GiB |
| Avg memory | 3.5 GiB |
| CPU user | 952.6s |
| CPU sys | 78.2s |
| Peak spill | 0 B |
</details>
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "jayzhan211 (via GitHub)" <gi...@apache.org>.
jayzhan211 commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5825599720
Thanks @Rachelint β this is very helpful, and it is useful to know #23186 hit the same wall from the other direction.
First, housekeeping: I have split this series into two reviewable PRs and rebased both onto current main (needed anyway after #25538 moved the spill contexts into `aggregates/spill.rs`):
- **#25724** β the complete final-stage feature, 6 commits, off by default
- **#25725** β the single-stage `SinglePartitioned` extension, stacked on it
This PR is superseded by those; happy to close it once you have had a look.
## On string group keys
Two commits landed after you looked here, and both target exactly this case:
- the table moves into buckets at a **quarter** of the threshold when the input holds about one row per group, so far less work is repeated;
- **the table of a bucket keeps its group keys where its input already holds them** instead of copying every new key into its own builder. A bucket's rows sit in one contiguous block that is dropped as soon as that bucket has been aggregated, so the table can store a view into that block. This removes 17-19 ns per row on multi-column string keys β Q14's group-id time goes 44.7 β 25.7 ns/row, Q16 54.8 β 46.9.
On #25724's tree, ClickBench per query, off/on back to back, 3 rounds of the fastest of 3 iterations (M4 Pro, 12 partitions, threshold 262144), the string-keyed queries now look like this:
| query | group key | groups / partition | ratio |
|---|---|---|---|
| Q18 | `UserID, minute, SearchPhrase` | 4.7 M | **0.56x** |
| Q33 | `URL` | 1.5 M | **0.63x** |
| Q34 | `1, URL` | 1.5 M | **0.87x** |
| Q11 | `SearchPhrase` | ~0.5 M | 1.02x |
| Q12 | `SearchPhrase` | 502 k | 1.07x |
| Q14 | `SearchEngineID, SearchPhrase` | 539 k | 1.08x |
Total 20.65 s β 17.25 s = 0.835x.
So **Q33 and Q34 are wins here rather than regressions**, which makes me think the discriminator is not the column type but the group count: everything at or above ~1.5M groups per partition wins, everything at 0.5-1M loses. If we disabled bucketing whenever a group key is a string we would give up 0.56x, 0.63x and 0.87x on the three largest string aggregations, which are precisely the ones this is meant to help.
## On `MutableArrayData` and a column-oriented coalescer
I owe you a negative result here, because I tried the closest thing available today and it went the wrong way.
Arrow's `BatchCoalescer::push_batch_with_filter` has a fused sparse path: at 1/64 selectivity it filters the views of a `Utf8View` column and **reuses the source data buffers**, so no string bytes are copied at all, and the `take` disappears too. I replaced the take + slice + per-bucket push with one selection mask per bucket and that call.
Routing got cheaper exactly as intended:
| | routing, ns/row | finding group ids, ns/row |
|---|---|---|
| Q14 | 44.1 β **28.7** | 45.4 β **78.7** |
| Q12 | 37.0 β **22.8** | 57.1 β **91.9** |
| Q31 (no strings) | 29.6 β 36.5 | 10.1 β 9.7 |
β¦but interning got much more expensive, and every query got slower (Q13 1.07 β 1.21, Q16 1.00 β 1.14, Q18 0.53 β 0.63). The conclusion I drew is that **the coalescer's garbage-collection copy is not waste**: it packs each bucket's strings into one contiguous, bucket-local block, which is exactly what makes that bucket's small table fast afterwards. Sharing the input's buffers instead leaves a bucket's keys scattered across every buffer the input arrived in. Q31 is the control β no strings, so interning is unchanged, and routing gets *worse* because arrow rescans the whole mask once per bucket.
I mention it because `MutableArrayData` also `Arc`-clones the variadic buffers for view types rather than copying the bytes, so a bucket batch built that way would share buffers in the same way. That may be part of what you saw on Q33/Q34 β offered as a hypothesis about the mechanism, not a claim about your implementation, since I have not run it.
The corollary for the arrow ask is that a public `InProgressArray` would help most if it still **compacts per destination**; a zero-copy view-sharing scatter appears to lose more downstream than it saves. I would be glad to help push on that if you pick it up.
For what it is worth I also tried moving the bucketing into `RepartitionExec`, in two variants (per-destination slices of one grouped take, and `interleave` over 16 held batches), and both were slower than doing it in the final aggregation β which matches your result. With 12 partitions Γ 64 buckets an 8192-row batch becomes 768 slices of ~10 rows, and the per-slice cost dominates.
## What is genuinely still unresolved
Q11/Q12/Q14, at 0.5-1M groups per partition, are 1.02-1.08x. I do not think this is a tuning problem:
- On Q12 the **CPU is a wash** β the final aggregate costs 76 ms more and the partial aggregate 68 ms less, summed over all partitions, net β0.7 ms. The 7% is wall clock: without buckets the final stage interns every row as it arrives, overlapped with the scan, while with buckets it only routes during the scan and aggregates after the input ends.
- A smarter trigger does not help. A larger threshold, a self-timing trigger, and holding the input back until it proves large were all built and measured; each only moved the loss to other queries. In particular **engaging later is worse than never engaging**: Q33's final aggregate takes 12.4 s of compute if it never buckets, 3.5 s if it buckets at 65k groups, and 25.8 s if it buckets at 1M, because a table that has already grown has already paid the penalty and then pays the routing on top.
So the decision has to be made before the table grows β a prediction, not a reaction β which is why the option stays off by default in #25724 and why I have not proposed flipping it. If it ever were flipped, two tests that encode today's behaviour would need updating: `aggregate_fuzz::streaming_aggregate_test` (a flushing partial aggregation legitimately emits a group more than once) and `ordered_aggregate_spill.slt` (it asserts the final aggregate spills, and with buckets it sometimes no longer needs to).
A benchmark-bot run against #25724 with `DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"` would be very welcome β my numbers are from a single laptop, and the cliff this targets depends on cache and core count, so your `c4a-highmem-16` with 80 MiB of L3 may well place the crossover somewhere else.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "Rachelint (via GitHub)" <gi...@apache.org>.
Rachelint commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5852219697
Sorry, Iβve been away for the past two days. Iβm back home today and will take a detailed look.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5763250499
π€ Benchmark completed (GKE) | [trigger](https://github.com/apache/datafusion/pull/25567#issuecomment-5763080234)
**Instance:** `c4a-highmem-16` (12 vCPU / 65 GiB)
Comparing agg-bucketed-final (d4c6299a9ede9575990d8de7935dd5310981b69e) to 6574a8c (merge-base) [diff](https://github.com/apache/datafusion/compare/6574a8c3b2c93ef9689a677c1cc1c0a4a844617f..d4c6299a9ede9575990d8de7935dd5310981b69e)
<details><summary>Run configuration</summary>
```yaml
run benchmark clickbench_partitioned
changed:
env:
DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"
```
</details>
<details><summary>CPU Details (lscpu)</summary>
```
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: ARM
Model name: Neoverse-V2
Model: 1
Thread(s) per core: 1
Core(s) per cluster: 16
Socket(s): -
Cluster(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache: 1 MiB (16 instances)
L1i cache: 1 MiB (16 instances)
L2 cache: 32 MiB (16 instances)
L3 cache: 80 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerability Gather data sampling: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; CSV2, BHB
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
```
</details>
<details><summary>Details</summary>
<p>
```
Comparing HEAD and agg-bucketed-final
--------------------
Benchmark clickbench_partitioned.json
--------------------
βββββββββββββ³βββββββββββββ³βββββββββββββββββββββ³ββββββββββββββββ
β Query β HEAD β agg-bucketed-final β Change β
β‘ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ©
β QQuery 0 β 1.22 ms β 1.22 ms β no change β
β QQuery 1 β 11.66 ms β 11.67 ms β no change β
β QQuery 2 β 36.58 ms β 36.84 ms β no change β
β QQuery 3 β 31.00 ms β 31.08 ms β no change β
β QQuery 4 β 232.63 ms β 188.70 ms β +1.23x faster β
β QQuery 5 β 274.28 ms β 279.33 ms β no change β
β QQuery 6 β 1.27 ms β 1.31 ms β no change β
β QQuery 7 β 13.01 ms β 13.02 ms β no change β
β QQuery 8 β 331.00 ms β 293.19 ms β +1.13x faster β
β QQuery 9 β 470.54 ms β 468.52 ms β no change β
β QQuery 10 β 64.14 ms β 67.14 ms β no change β
β QQuery 11 β 75.78 ms β 77.79 ms β no change β
β QQuery 12 β 261.25 ms β 270.36 ms β no change β
β QQuery 13 β 357.77 ms β 372.96 ms β no change β
β QQuery 14 β 280.08 ms β 290.89 ms β no change β
β QQuery 15 β 280.38 ms β 220.53 ms β +1.27x faster β
β QQuery 16 β 611.96 ms β 645.96 ms β 1.06x slower β
β QQuery 17 β 623.37 ms β 587.96 ms β +1.06x faster β
β QQuery 18 β 1268.95 ms β 1161.90 ms β +1.09x faster β
β QQuery 19 β 27.37 ms β 27.61 ms β no change β
β QQuery 20 β 516.76 ms β 525.95 ms β no change β
β QQuery 21 β 503.75 ms β 516.70 ms β no change β
β QQuery 22 β 972.75 ms β 982.58 ms β no change β
β QQuery 23 β 3044.78 ms β 3073.37 ms β no change β
β QQuery 24 β 41.09 ms β 40.62 ms β no change β
β QQuery 25 β 104.71 ms β 104.73 ms β no change β
β QQuery 26 β 41.24 ms β 40.87 ms β no change β
β QQuery 27 β 512.60 ms β 509.83 ms β no change β
β QQuery 28 β 2906.57 ms β 2929.78 ms β no change β
β QQuery 29 β 41.51 ms β 41.45 ms β no change β
β QQuery 30 β 302.58 ms β 285.93 ms β +1.06x faster β
β QQuery 31 β 271.58 ms β 258.54 ms β no change β
β QQuery 32 β 931.16 ms β 744.51 ms β +1.25x faster β
β QQuery 33 β 1406.73 ms β 1415.45 ms β no change β
β QQuery 34 β 1445.94 ms β 1440.17 ms β no change β
β QQuery 35 β 289.77 ms β 229.52 ms β +1.26x faster β
β QQuery 36 β 66.77 ms β 66.61 ms β no change β
β QQuery 37 β 34.42 ms β 35.25 ms β no change β
β QQuery 38 β 41.46 ms β 42.21 ms β no change β
β QQuery 39 β 148.28 ms β 147.76 ms β no change β
β QQuery 40 β 14.07 ms β 14.73 ms β no change β
β QQuery 41 β 13.68 ms β 13.69 ms β no change β
β QQuery 42 β 12.80 ms β 13.22 ms β no change β
βββββββββββββ΄βββββββββββββ΄βββββββββββββββββββββ΄ββββββββββββββββ
βββββββββββββββββββββββββββββββββββββ³βββββββββββββ
β Benchmark Summary β β
β‘βββββββββββββββββββββββββββββββββββββββββββββββββ©
β Total Time (HEAD) β 18919.23ms β
β Total Time (agg-bucketed-final) β 18521.47ms β
β Average Time (HEAD) β 439.98ms β
β Average Time (agg-bucketed-final) β 430.73ms β
β Queries Faster β 8 β
β Queries Slower β 1 β
β Queries with No Change β 34 β
β Queries with Failure β 0 β
βββββββββββββββββββββββββββββββββββββ΄βββββββββββββ
Distribution per query (min / mean Β±stddev / max):
Comparing HEAD and agg-bucketed-final
--------------------
Benchmark clickbench_partitioned.json
--------------------
βββββββββββββ³ββββββββββββββββββββββββββββββββββββββββ³βββββββββββββββββββββββββββββββββββββββββ³ββββββββββββββββ
β Query β HEAD β agg-bucketed-final β Change β
β‘βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ©
β QQuery 0 β 1.22 / 3.95 Β±5.36 / 14.67 ms β 1.22 / 3.98 Β±5.47 / 14.92 ms β no change β
β QQuery 1 β 11.66 / 11.86 Β±0.13 / 11.98 ms β 11.67 / 11.80 Β±0.12 / 11.97 ms β no change β
β QQuery 2 β 36.58 / 36.80 Β±0.23 / 37.21 ms β 36.84 / 37.11 Β±0.25 / 37.53 ms β no change β
β QQuery 3 β 31.00 / 31.74 Β±0.64 / 32.89 ms β 31.08 / 32.95 Β±2.39 / 37.68 ms β no change β
β QQuery 4 β 232.63 / 237.41 Β±2.93 / 240.84 ms β 188.70 / 190.31 Β±1.70 / 193.46 ms β +1.25x faster β
β QQuery 5 β 274.28 / 279.42 Β±4.45 / 287.14 ms β 279.33 / 283.41 Β±3.93 / 288.52 ms β no change β
β QQuery 6 β 1.27 / 1.43 Β±0.23 / 1.89 ms β 1.31 / 1.47 Β±0.24 / 1.93 ms β no change β
β QQuery 7 β 13.01 / 13.29 Β±0.20 / 13.64 ms β 13.02 / 13.13 Β±0.09 / 13.24 ms β no change β
β QQuery 8 β 331.00 / 334.00 Β±2.52 / 338.65 ms β 293.19 / 296.22 Β±3.14 / 301.12 ms β +1.13x faster β
β QQuery 9 β 470.54 / 479.02 Β±6.97 / 488.02 ms β 468.52 / 473.78 Β±3.30 / 478.00 ms β no change β
β QQuery 10 β 64.14 / 65.78 Β±1.09 / 67.01 ms β 67.14 / 67.31 Β±0.22 / 67.72 ms β no change β
β QQuery 11 β 75.78 / 76.28 Β±0.73 / 77.73 ms β 77.79 / 78.94 Β±0.84 / 80.32 ms β no change β
β QQuery 12 β 261.25 / 264.09 Β±3.65 / 270.87 ms β 270.36 / 278.04 Β±8.60 / 294.84 ms β 1.05x slower β
β QQuery 13 β 357.77 / 364.73 Β±5.39 / 371.09 ms β 372.96 / 380.82 Β±3.99 / 383.55 ms β no change β
β QQuery 14 β 280.08 / 284.85 Β±3.83 / 290.69 ms β 290.89 / 294.05 Β±2.39 / 296.58 ms β no change β
β QQuery 15 β 280.38 / 296.17 Β±14.27 / 319.15 ms β 220.53 / 225.94 Β±4.69 / 233.14 ms β +1.31x faster β
β QQuery 16 β 611.96 / 620.63 Β±6.82 / 631.37 ms β 645.96 / 659.22 Β±9.21 / 669.69 ms β 1.06x slower β
β QQuery 17 β 623.37 / 631.83 Β±6.67 / 643.65 ms β 587.96 / 605.29 Β±16.52 / 628.12 ms β no change β
β QQuery 18 β 1268.95 / 1288.91 Β±13.64 / 1308.44 ms β 1161.90 / 1233.77 Β±42.80 / 1285.42 ms β no change β
β QQuery 19 β 27.37 / 33.33 Β±11.50 / 56.33 ms β 27.61 / 27.81 Β±0.16 / 28.01 ms β +1.20x faster β
β QQuery 20 β 516.76 / 535.42 Β±21.38 / 573.19 ms β 525.95 / 549.13 Β±34.65 / 617.73 ms β no change β
β QQuery 21 β 503.75 / 508.00 Β±2.53 / 510.45 ms β 516.70 / 528.99 Β±14.29 / 555.67 ms β no change β
β QQuery 22 β 972.75 / 981.66 Β±6.86 / 992.73 ms β 982.58 / 1000.83 Β±14.28 / 1024.97 ms β no change β
β QQuery 23 β 3044.78 / 3080.50 Β±26.90 / 3122.96 ms β 3073.37 / 3116.90 Β±37.22 / 3163.29 ms β no change β
β QQuery 24 β 41.09 / 50.98 Β±9.02 / 67.58 ms β 40.62 / 42.80 Β±3.40 / 49.55 ms β +1.19x faster β
β QQuery 25 β 104.71 / 106.09 Β±1.13 / 107.29 ms β 104.73 / 106.39 Β±1.15 / 107.88 ms β no change β
β QQuery 26 β 41.24 / 42.46 Β±1.69 / 45.78 ms β 40.87 / 41.71 Β±0.81 / 43.09 ms β no change β
β QQuery 27 β 512.60 / 520.48 Β±6.61 / 529.01 ms β 509.83 / 518.31 Β±4.94 / 524.62 ms β no change β
β QQuery 28 β 2906.57 / 2936.86 Β±21.59 / 2959.94 ms β 2929.78 / 2949.44 Β±18.94 / 2975.76 ms β no change β
β QQuery 29 β 41.51 / 48.12 Β±8.50 / 62.68 ms β 41.45 / 44.79 Β±5.92 / 56.62 ms β +1.07x faster β
β QQuery 30 β 302.58 / 308.29 Β±4.12 / 314.10 ms β 285.93 / 302.96 Β±26.61 / 355.23 ms β no change β
β QQuery 31 β 271.58 / 280.98 Β±7.17 / 288.27 ms β 258.54 / 270.49 Β±11.70 / 290.46 ms β no change β
β QQuery 32 β 931.16 / 943.60 Β±20.14 / 983.80 ms β 744.51 / 761.58 Β±10.73 / 773.64 ms β +1.24x faster β
β QQuery 33 β 1406.73 / 1454.84 Β±32.80 / 1488.31 ms β 1415.45 / 1548.81 Β±113.76 / 1729.83 ms β 1.06x slower β
β QQuery 34 β 1445.94 / 1500.67 Β±41.37 / 1560.55 ms β 1440.17 / 1525.68 Β±68.94 / 1633.22 ms β no change β
β QQuery 35 β 289.77 / 300.36 Β±14.08 / 327.52 ms β 229.52 / 281.95 Β±45.66 / 359.34 ms β +1.07x faster β
β QQuery 36 β 66.77 / 77.41 Β±10.93 / 97.47 ms β 66.61 / 75.79 Β±4.98 / 81.79 ms β no change β
β QQuery 37 β 34.42 / 35.49 Β±0.83 / 36.97 ms β 35.25 / 39.21 Β±7.07 / 53.33 ms β 1.10x slower β
β QQuery 38 β 41.46 / 47.07 Β±5.63 / 56.69 ms β 42.21 / 46.17 Β±4.18 / 53.04 ms β no change β
β QQuery 39 β 148.28 / 154.96 Β±10.70 / 176.30 ms β 147.76 / 157.16 Β±5.76 / 164.59 ms β no change β
β QQuery 40 β 14.07 / 14.45 Β±0.22 / 14.67 ms β 14.73 / 16.61 Β±2.39 / 21.07 ms β 1.15x slower β
β QQuery 41 β 13.68 / 16.69 Β±3.55 / 22.80 ms β 13.69 / 14.25 Β±0.53 / 15.22 ms β +1.17x faster β
β QQuery 42 β 12.80 / 13.07 Β±0.21 / 13.42 ms β 13.22 / 14.76 Β±2.81 / 20.39 ms β 1.13x slower β
βββββββββββββ΄ββββββββββββββββββββββββββββββββββββββββ΄βββββββββββββββββββββββββββββββββββββββββ΄ββββββββββββββββ
βββββββββββββββββββββββββββββββββββββ³βββββββββββββ
β Benchmark Summary β β
β‘βββββββββββββββββββββββββββββββββββββββββββββββββ©
β Total Time (HEAD) β 19313.95ms β
β Total Time (agg-bucketed-final) β 19150.08ms β
β Average Time (HEAD) β 449.16ms β
β Average Time (agg-bucketed-final) β 445.35ms β
β Queries Faster β 9 β
β Queries Slower β 6 β
β Queries with No Change β 28 β
β Queries with Failure β 0 β
βββββββββββββββββββββββββββββββββββββ΄βββββββββββββ
```
</p>
</details>
<details><summary>Resource Usage</summary>
**clickbench_partitioned β base (merge-base)**
| Metric | Value |
|--------|-------|
| Wall time | 100.0s |
| Peak memory | 10.7 GiB |
| Avg memory | 4.0 GiB |
| CPU user | 989.7s |
| CPU sys | 67.1s |
| Peak spill | 0 B |
**clickbench_partitioned β branch**
| Metric | Value |
|--------|-------|
| Wall time | 100.0s |
| Peak memory | 10.0 GiB |
| Avg memory | 3.8 GiB |
| CPU user | 945.9s |
| CPU sys | 76.0s |
| Peak spill | 0 B |
</details>
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "Rachelint (via GitHub)" <gi...@apache.org>.
Rachelint commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5770739208
run benchmark clickbench_partitioned
changed:
env:
DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5763126681
π€ Benchmark running (GKE) | [trigger](https://github.com/apache/datafusion/pull/25567#issuecomment-5763080234)
**Instance:** `c4a-highmem-16` (12 vCPU / 65 GiB) | `Linux bench-c5763080234-2548-s54kw 6.12.94+ #1 SMP Tue Aug 4 08:44:15 UTC 2026 aarch64 GNU/Linux`
<details><summary>CPU Details (lscpu)</summary>
```
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: ARM
Model name: Neoverse-V2
Model: 1
Thread(s) per core: 1
Core(s) per cluster: 16
Socket(s): -
Cluster(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache: 1 MiB (16 instances)
L1i cache: 1 MiB (16 instances)
L2 cache: 32 MiB (16 instances)
L3 cache: 80 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerability Gather data sampling: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; CSV2, BHB
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
```
</details>
Comparing agg-bucketed-final (d4c6299a9ede9575990d8de7935dd5310981b69e) to 6574a8c (merge-base) [diff](https://github.com/apache/datafusion/compare/6574a8c3b2c93ef9689a677c1cc1c0a4a844617f..d4c6299a9ede9575990d8de7935dd5310981b69e)
<details><summary>Run configuration</summary>
```yaml
run benchmark clickbench_partitioned
changed:
env:
DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"
```
</details>
Results will be posted here when complete
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "Rachelint (via GitHub)" <gi...@apache.org>.
Rachelint commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5770623516
run benchmark clickbench_partitioned
changed:
env:
DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "Rachelint (via GitHub)" <gi...@apache.org>.
Rachelint commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5770497307
run benchmark clickbench_partitioned
changed:
env:
DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "Rachelint (via GitHub)" <gi...@apache.org>.
Rachelint commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5763080234
run benchmark clickbench_partitioned
changed:
env:
DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5770645984
π€ Benchmark running (GKE) | [trigger](https://github.com/apache/datafusion/pull/25567#issuecomment-5770623516)
**Instance:** `c4a-highmem-16` (12 vCPU / 65 GiB) | `Linux bench-c5770623516-2573-qvmnr 6.12.94+ #1 SMP Wed Aug 19 07:47:20 UTC 2026 aarch64 GNU/Linux`
<details><summary>CPU Details (lscpu)</summary>
```
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: ARM
Model name: Neoverse-V2
Model: 1
Thread(s) per core: 1
Core(s) per cluster: 16
Socket(s): -
Cluster(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache: 1 MiB (16 instances)
L1i cache: 1 MiB (16 instances)
L2 cache: 32 MiB (16 instances)
L3 cache: 80 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerability Gather data sampling: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; CSV2, BHB
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
```
</details>
Comparing agg-bucketed-final (d4c6299a9ede9575990d8de7935dd5310981b69e) to 6574a8c (merge-base) [diff](https://github.com/apache/datafusion/compare/6574a8c3b2c93ef9689a677c1cc1c0a4a844617f..d4c6299a9ede9575990d8de7935dd5310981b69e)
<details><summary>Run configuration</summary>
```yaml
run benchmark clickbench_partitioned
changed:
env:
DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"
```
</details>
Results will be posted here when complete
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "codecov-commenter (via GitHub)" <gi...@apache.org>.
codecov-commenter commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5763980410
## [Codecov](https://app.codecov.io/gh/apache/datafusion/pull/25567?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) Report
:x: Patch coverage is `87.57108%` with `153 lines` in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 82.43%. Comparing base ([`6574a8c`](https://app.codecov.io/gh/apache/datafusion/commit/6574a8c3b2c93ef9689a677c1cc1c0a4a844617f?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)) to head ([`d4c6299`](https://app.codecov.io/gh/apache/datafusion/commit/d4c6299a9ede9575990d8de7935dd5310981b69e?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)).
:warning: Report is 5 commits behind head on main.
| [Files with missing lines](https://app.codecov.io/gh/apache/datafusion/pull/25567?dropdown=coverage&src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Patch % | Lines |
|---|---|---|
| [...fusion/physical-plan/src/aggregates/hash\_stream.rs](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&filepath=datafusion%2Fphysical-plan%2Fsrc%2Faggregates%2Fhash_stream.rs&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-ZGF0YWZ1c2lvbi9waHlzaWNhbC1wbGFuL3NyYy9hZ2dyZWdhdGVzL2hhc2hfc3RyZWFtLnJz) | 89.36% | [10 Missing and 47 partials :warning: ](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [...sion/physical-plan/src/aggregates/final\_buckets.rs](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&filepath=datafusion%2Fphysical-plan%2Fsrc%2Faggregates%2Ffinal_buckets.rs&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-ZGF0YWZ1c2lvbi9waHlzaWNhbC1wbGFuL3NyYy9hZ2dyZWdhdGVzL2ZpbmFsX2J1Y2tldHMucnM=) | 86.69% | [8 Missing and 29 partials :warning: ](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [...ysical-plan/src/aggregates/bucketed\_aggregation.rs](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&filepath=datafusion%2Fphysical-plan%2Fsrc%2Faggregates%2Fbucketed_aggregation.rs&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-ZGF0YWZ1c2lvbi9waHlzaWNhbC1wbGFuL3NyYy9hZ2dyZWdhdGVzL2J1Y2tldGVkX2FnZ3JlZ2F0aW9uLnJz) | 84.79% | [10 Missing and 23 partials :warning: ](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [...sion/physical-plan/src/aggregates/single\_stream.rs](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&filepath=datafusion%2Fphysical-plan%2Fsrc%2Faggregates%2Fsingle_stream.rs&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-ZGF0YWZ1c2lvbi9waHlzaWNhbC1wbGFuL3NyYy9hZ2dyZWdhdGVzL3NpbmdsZV9zdHJlYW0ucnM=) | 80.37% | [16 Missing and 5 partials :warning: ](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [...src/aggregates/aggregate\_hash\_table/final\_table.rs](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&filepath=datafusion%2Fphysical-plan%2Fsrc%2Faggregates%2Faggregate_hash_table%2Ffinal_table.rs&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-ZGF0YWZ1c2lvbi9waHlzaWNhbC1wbGFuL3NyYy9hZ2dyZWdhdGVzL2FnZ3JlZ2F0ZV9oYXNoX3RhYmxlL2ZpbmFsX3RhYmxlLnJz) | 90.00% | [3 Missing :warning: ](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
| [...plan/src/aggregates/aggregate\_hash\_table/common.rs](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&filepath=datafusion%2Fphysical-plan%2Fsrc%2Faggregates%2Faggregate_hash_table%2Fcommon.rs&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-ZGF0YWZ1c2lvbi9waHlzaWNhbC1wbGFuL3NyYy9hZ2dyZWdhdGVzL2FnZ3JlZ2F0ZV9oYXNoX3RhYmxlL2NvbW1vbi5ycw==) | 96.72% | [0 Missing and 2 partials :warning: ](https://app.codecov.io/gh/apache/datafusion/pull/25567?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
<details><summary>Additional details and impacted files</summary>
```diff
@@ Coverage Diff @@
## main #25567 +/- ##
==========================================
+ Coverage 82.42% 82.43% +0.01%
==========================================
Files 1138 1140 +2
Lines 435501 436707 +1206
Branches 435501 436707 +1206
==========================================
+ Hits 358955 360002 +1047
- Misses 54841 54891 +50
- Partials 21705 21814 +109
```
</details>
[:umbrella: View full report in Codecov by Harness](https://app.codecov.io/gh/apache/datafusion/pull/25567?dropdown=coverage&src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
:loudspeaker: Have feedback on the report? [Share it here](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
<details><summary> :rocket: New features to boost your workflow: </summary>
- :snowflake: [Test Analytics](https://docs.codecov.com/docs/test-analytics): Detect flaky tests, report on failures, and find test suite problems.
- :package: [JS Bundle Analysis](https://docs.codecov.com/docs/javascript-bundle-analysis): Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "Rachelint (via GitHub)" <gi...@apache.org>.
Rachelint commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5765694179
I experiment the similar idea in https://github.com/apache/datafusion/pull/23186 before, and see similar improvements, so I think it maybe really promising.
However, as the PR description notes, there are still some unresolved issues preventing this idea to be ready.
## For string group values case
> Where the remaining loss comes from (per final input row): Q14 costs 79-85 ns with one table and 91-99 ns bucketed...
I previously tried moving the entire bucketing step into RepartitionExec, but the results were disappointing: it was noticeably slower than splitting into buckets inside the final aggregation. My current hypothesis is that this may be related to the repartition coalescer being shared across multiple producer tasks, whereas the extra hashing and copying in the final aggregation are local to a single stream. However, I have not confirmed this yet.
That said, if we cannot avoid repartitioning the RecordBatch again inside the final aggregation, there seems to be little or no benefit for string group keys, and it can even cause a regression. This has been troubling me for a while. It is not limited to Q12βQ14 either; Q33 and Q34 also show significant regressions.
## Another possible opportunity to improve performance
In my experiments, slicing a batch and pushing each slice into a per-bucket coalescer was not particularly fast. In [#23186](https://github.com/apache/datafusion/pull/23186), it even caused a performance regression(so actually I was surprised that this PR still achieves substantial overall improvements while using slice + coalescer).
I later switched to MutableArrayData to build the bucket batches column by column, which improved this part of the process. A similar approach might be worth exploring as a follow-up optimization for this PR.
The implementation was rather awkward, however, because MutableArrayData does not support continuously appending after an output array has been materialized. What I really wanted was a column-oriented coalescerβessentially direct access to the InProgressArray abstraction used internally by Arrowβs BatchCoalescer.
I have wanted to fork Arrow and experiment with exposing that interface publicly, but unfortunately I have not had time to do so yet.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5762683906
π€ Benchmark running (GKE) | [trigger](https://github.com/apache/datafusion/pull/25567#issuecomment-5762634475)
**Instance:** `c4a-highmem-16` (12 vCPU / 65 GiB) | `Linux bench-c5762634475-2546-fdk96 6.12.94+ #1 SMP Tue Aug 4 08:44:15 UTC 2026 aarch64 GNU/Linux`
<details><summary>CPU Details (lscpu)</summary>
```
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: ARM
Model name: Neoverse-V2
Model: 1
Thread(s) per core: 1
Core(s) per cluster: 16
Socket(s): -
Cluster(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache: 1 MiB (16 instances)
L1i cache: 1 MiB (16 instances)
L2 cache: 32 MiB (16 instances)
L3 cache: 80 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerability Gather data sampling: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; CSV2, BHB
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
```
</details>
Comparing agg-bucketed-final (d4c6299a9ede9575990d8de7935dd5310981b69e) to 6574a8c (merge-base) [diff](https://github.com/apache/datafusion/compare/6574a8c3b2c93ef9689a677c1cc1c0a4a844617f..d4c6299a9ede9575990d8de7935dd5310981b69e)
<details><summary>Run configuration</summary>
```yaml
run benchmark clickbench_partitioned
```
</details>
Results will be posted here when complete
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5770800249
π€ Benchmark running (GKE) | [trigger](https://github.com/apache/datafusion/pull/25567#issuecomment-5770778035)
**Instance:** `c4a-highmem-16` (12 vCPU / 65 GiB) | `Linux bench-c5770778035-2576-92xmt 6.12.94+ #1 SMP Wed Aug 19 07:47:20 UTC 2026 aarch64 GNU/Linux`
<details><summary>CPU Details (lscpu)</summary>
```
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: ARM
Model name: Neoverse-V2
Model: 1
Thread(s) per core: 1
Core(s) per cluster: 16
Socket(s): -
Cluster(s): 1
Stepping: r0p1
BogoMIPS: 2000.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache: 1 MiB (16 instances)
L1i cache: 1 MiB (16 instances)
L2 cache: 32 MiB (16 instances)
L3 cache: 80 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerability Gather data sampling: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; CSV2, BHB
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Not affected
```
</details>
Comparing agg-bucketed-final (d4c6299a9ede9575990d8de7935dd5310981b69e) to 6574a8c (merge-base) [diff](https://github.com/apache/datafusion/compare/6574a8c3b2c93ef9689a677c1cc1c0a4a844617f..d4c6299a9ede9575990d8de7935dd5310981b69e)
<details><summary>Run configuration</summary>
```yaml
run benchmark clickbench_partitioned
changed:
env:
DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"
```
</details>
Results will be posted here when complete
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "Rachelint (via GitHub)" <gi...@apache.org>.
Rachelint commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5770778035
run benchmark clickbench_partitioned
changed:
env:
DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD: "262144"
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org
Re: [PR] feat: aggregate large hash tables as hash buckets (experimental, off by default) [datafusion]
Posted by "adriangbot (via GitHub)" <gi...@apache.org>.
adriangbot commented on PR #25567:
URL: https://github.com/apache/datafusion/pull/25567#issuecomment-5770739293
Hi @Rachelint, your benchmark configuration could not be parsed (https://github.com/apache/datafusion/pull/25567#issuecomment-5770739208).
**Error:** `invalid configuration: unknown field `DATAFUSION_EXECUTION_HASH_AGGREGATE_BUCKET_THRESHOLD`, expected one of `env`, `baseline`, `changed` at line 3 column 1`
Usage:
```
run benchmark <name> # run specific benchmark(s)
run benchmarks # run default suite
run benchmarks <name1> <name2> # run specific benchmarks
```
Any benchmark name is accepted: `bench.sh` suite names (e.g. `tpch`, `clickbench_partitioned`, `wide_schema`) and Criterion bench targets (e.g. `sql_planner`) are resolved automatically. A name that matches neither fails on the runner.
Per-side configuration (`run benchmark tpch` followed by):
```yaml
env:
# shared env is inherited by BOTH the build and the run, so build
# flags go here. Builds default to no debuginfo for speed; opt back
# in for hung-job gdb dumps and cap jobs to stay within memory:
CARGO_PROFILE_RELEASE_DEBUG: "1"
CARGO_BUILD_JOBS: "1"
baseline:
ref: v45.0.0
env:
# per-side env only reaches the benchmark run, not the build
DATAFUSION_RUNTIME_MEMORY_LIMIT: 1G
changed:
ref: v46.0.0
env:
DATAFUSION_RUNTIME_MEMORY_LIMIT: 2G
```
---
[File an issue](https://github.com/adriangb/datafusion-benchmarking/issues) against this benchmark runner
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscribe@datafusion.apache.org
For additional commands, e-mail: github-help@datafusion.apache.org