Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

@alexey-milovidov
@nickitat this is at least worth reading:
https://presentations.clickhouse.com/hse_2020/4th/GroupBySpeedup_pres.pdf
https://presentations.clickhouse.com/hse_2020/4th/GroupBySpeedup_full.pdf
#10956

@nickitat
I’ve read it, the experiment itself looks interesting. I personally don’t really believe that the fastest aggr implementation would be a concurrent one (and we see that even on 32 threads the author was made to increase number of buckets twice because of contention). It should be parallel (data parallel). So IMO more perspective direction would be to try to implement splitting aggregator as efficient as possible. maybe vectorise hash calculation, do not copy rows (only create vector of indices for each partition), reuse calculated hash, maybe smth else. This approach will do only one insertion into HT, have constant overhead per row and no scalability issues. it would be also reusable in distinct, limit by, maybe window functions.
wdyt? (edited)

@alexey-milovidov
Yes, I also think similarly. This approach is also harder to use with distributed aggregation.