Optimize DECIMAL128 sum aggregations [databricks]

[jlowe]

Depends on rapidsai/cudf#10201.

This accelerates sum aggregations on DECIMAL128 by splitting up the 128-bit values into 32-bit chunks, summing the chunks separately into 64-bit accumulated values, and then reassembling the 128-bit value from the accumulated chunks (with overflow checking). This changes what would normally force a cudf sort-based aggregation into one that can be hash-based which can significantly improve performance. This also allows us to remove some of the DECIMAL128 overflow code.

[jlowe]

build

[revans2]

The main thing I would like to see is follow on work to do the same kind of thing for average. We also should look at SUM for window operations. I don't think it will be needed there because the data comes in sorted, but some of the cleanup that has been done to split decimal from others would be good there too.

[jlowe]

build

[jlowe]

Tracked down the CI failure to a libcudf issue with sort-based sum aggregations not performing aggregations in the result type as hash-based aggregations do. Filed rapidsai/cudf#10246. In the meantime, I'll update this to pre-cast the inputs to avoid the issue.

[jlowe]

@abellina your comments should now be addressed.

Note that this also includes a change to lower the batch size being used in hash_aggregate_tests for exercising out-of-core hash aggregate processing, as the 312db failure from the previous CI run was triggered by such processing. We were not seeing it in other CI runs because we weren't regularly exercising this code path, but we do with the new lower batch size value. This adds approx 5 minutes of test time on my desktop (with 4-way parallelism), but it seems worth it for the extra coverage.

[jlowe]

build

[abellina]

One more nit on an override

[jlowe]

build