Optimizing Aggregate Holder Array using ThreadLocal arrays

[beroy]

Objective

Memory profiling shows +DoubleGroupByResultHolder+ contributing ~54GB of heap allocations during group-by query processing. The allocation pressure comes from the double[] arrays used to store per-group aggregation results, which are indexed by group key ID. The idea here is that by reusing thread-level arrays, we can significantly reduce the memory pressure on the GroupBy heavy workloads. This is assuming most of the time, the size of segments are equal or relatively close.

Testing

For the following query:

SELECT group_col, 
       MAX(metric_a), SUM(metric_b), MIN(metric_c), COUNT(metric_d) 
       FROM GROUP BY group_col 
       ORDER BY MAX(metric_a) DESC LIMIT 100

rows/segment	Master	Optimization	Saved	%
1M	30.5 MB/q	25.5 MB/q	5.0 MB	16.4%
5M	30.7 MB/q	25.7 MB/q	5.0 MB	16.3%

The optimization delivers a clean 5 MB/query saving (~16% of per-query allocation).

[siddharthteotia]

Suggest adding the technical rationale in the PR description on why we think ThreadLocal Setup will fix the problem. Part of me thinks that we are transferring the problem to YoungGen Pressure ? But may be that is ok and will be short lived and reclaimed in the next GC cycle. ? Is that the idea ?

Also suggest using JMH with -prof gc or the more sophisticated memory profiling via JFR or AsyncProfiler and then use tools like MAT , GCEasy or GCView.