Benchmark multi-column GROUP BY performance

[nathanb9]

Which issue does this PR close?

• Measuring: In general the multi group by option seems to make certain scenarios worse. #17850

Rationale for this change

1. Measure multi-column GROUP BY performance with a fair apples-to-apples comparison
2. The default vectorized per-column approach (GroupValuesColumn) underperforms the row-based approach (GroupValuesRows) when distinct group count is small relative
   to input rows. The benchmark confirms this: row-based is 16-19% faster below ~200K groups, while vectorized wins by 15-33% above ~500K groups.

What changes are included in this PR?

Adds a benchmark in datafusion/physical-plan/benches/multi_group_by.rs that directly calls GroupValues::intern() with identical Int32 data for both implementations —
no SQL/planning/IO overhead, same schema, same hashing.

Makes mod row public so the benchmark can instantiate GroupValuesRows directly.

Test cases:

• Issue In general the multi group by option seems to make certain scenarios worse. #17850 reproduction (3 cols, 64 groups, 1M-50M rows) — confirms row-based wins ~16-19%
• Low cardinality sweep (8-4096 groups, 3-4 cols) — row-based wins 15-38%
• Batch size sensitivity (1K-32K) — minimal effect on ratio
• Column scaling with low groups (2-10 cols) — row-based advantage grows with columns
• High cardinality scaling (1M groups, 2-10 cols) — vectorized wins 22-43%
• Group count sweep (16 to 1M groups, 4 cols) — crossover at ~200K-500K groups

Are these changes tested?

• cargo fmt --all
• cargo clippy -p datafusion-physical-plan --bench multi_group_by -- -D warnings
• cargo bench -p datafusion-physical-plan --bench multi_group_by

Are there any user-facing changes?

No. This adds a benchmark only.

[kosiew]

@nathanb9
Thanks for putting this benchmark together.
I think there are a few issues that make it hard to validate the conclusions the PR is trying to draw around GroupValuesColumn vs GroupValuesRows behavior.

[nathanb9]

Thanks for the review @kosiew.

Changes from your comments:

1. Both GroupValuesColumn and GroupValuesRows are now benchmarked directly via the intern() API with identical Int32 data
2. Benchmark bypasses SQL/planning entirely
3. Exact cardinality via sequential enumeration. Labels now match actual distinct group counts.

One thing im not sure about: making mod row public. This is needed because new_group_values() with an Int32 schema will always route to GroupValuesColumn. There's no way to make it pick GroupValuesRows for Int32 without. I can make it so only thing pub is pub use row::GroupValuesRows;

[kosiew]

@nathanb9
Thanks for the updates here. The benchmark changes address the earlier concerns around comparing GroupValuesColumn vs GroupValuesRows directly and removing SQL planning overhead from the measured path.

I still found one issue with the 1M-group benchmark cases. Because generate_batches truncates to whole batches, the generated input for the advertised 1_000_000 row/group cases is actually smaller than the benchmark labels suggest.

[kosiew]

@nathanb9
Thanks for the iteration.

Looks 👍 to me

[nathanb9]

@kosiew Thanks for your thorough review