Asthenia0412 opened a new pull request, #53812: URL: https://github.com/apache/arrow/pull/53812
## Background Issue #45847: Acero HashAggregate performs very poorly on multi-batch scenarios with the build side (32+ batches). Performance drops 10x+ and only 1 CPU core is used. ## Problem SwissTable::map_new_keys in key_map_internal.cc starts with log_blocks_=0 (8 slots) and calls grow_double() each time capacity is exceeded. For N unique keys this causes O(log N) separate resize operations. With 2M unique keys from 64x32K batches, cascading resize dominates execution time. ## Solution Pre-compute target capacity before the do-while loop and perform all needed grows in one batch. Small tables use 50% load factor, large tables use 75% (matching num_groups_for_resize). If multiple grows needed, bulk-resize once. Changes: +44 lines, 0 deleted in key_map_internal.cc ## Testing - Existing arrow-compute-row-test (Grouper): 83/83 PASS - Existing arrow-acero-hash-aggregate-test: 97/97 PASS - Build: arrow_compute_shared, arrow_acero_shared both compile cleanly Fixes: #45847 -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
