multi dictionary benchmarks

[Rich-T-kid]

Which issue does this PR close?

Works towards closing #21878

Rationale for this change

There is currently no benchmarks that cover GroupValueRow() when dictionary arrays are passed in. #22004 adds benchmarks for the single single column case. This PR adds benchmarks for the multi column case

What changes are included in this PR?

Adds a new Criterion harness for GroupValues over multi-column Dictionary<UInt64, Utf8> GROUP BY workloads, covering 4 and 8 group-by columns across batch sizes of 8 KiB and 64 KiB rows. It tests four realistic cardinalities (20, 100, 500, 1 000 distinct values) with per-column variance introduced by sampling each column's distinct count from a ±5% window around the target, so columns within the same batch have slightly different cardinalities. Two benchmark variants are included — repeated intern+emit and a partial-emit pattern that spills half the accumulated groups after each intern — to stress both the steady-state and incremental-flush paths of the group values implementation.

Are these changes tested?

n/a

Are there any user-facing changes?

No

[Rich-T-kid]

going to take another review tomorrow before pinging a reviewer to take a look!

[Rich-T-kid]

I think we should add a value type as a parameter here. strings are currently covered, in the future it may make sense for other types to also be covered. I left that out for this PR but I can introduce it if needed.

[Rich-T-kid]

I think that types that need to be benchmarks include (utf8, List<utf8>,Binary). I don't think their variants. (utf8View,List,binaryView...ect>,binaryView,LargeBinary,FixedSizeBinary) add enough difference to the point that there be any meaningful performance differences.
is there any recommendation on how to do this without multiplying the number of benchmarks we need to run by 3x?

[Rich-T-kid]

if/when we introduce other value data types, this function needs to change

[Rich-T-kid]

Should I also include a 1-1 cardinality ratio similar to #21765?

[Rich-T-kid]

@kumarUjjawal could you take a look a this and #22888 when you get a chance? Thank you

[kumarUjjawal]

Thank you @Rich-T-kid

Left couple of comments, let me know what you think.

[kumarUjjawal]

We should generate shared row group ids first, then map each group id to a multi-column tuple. That keeps total group combinations near target_distinct

[Rich-T-kid]

good catch! previously column_count * distinct was being generated. I've updated the code to generate the group id's first and then pass it into the creation of the dictionarys. this way no matter how many columns get produced they will produce the same number of group id's.

Ive also added benchmarks for the cross-product group-bys to try and better reflect the worse case scenario. ex

GROUP BY department, city,rank

as opposed to the current benchmarks that cover the case of group-bys where the row-space may be shared. ex

GROUP BY employee_id, department, manager_id

[Rich-T-kid]

Thanks for the review and comments @kumarUjjawal. Ive updated the PR could you take another look?

[kumarUjjawal]

@Rich-T-kid I was running this locally and I think this benchmark in not registered anywhere, I added it to the cargo toml only then it ran. Could you verify locally?

[Rich-T-kid]

I forgot to include the cargo file in the commit. should be good to go now @kumarUjjawal

[Rich-T-kid]

I replaced CARDS = [20, 100, 500, 1_000] (total distinct groups) with PER_COL_CARDS = [3, 4, 5, 6] (values per column), so cross-products stay below batch size and group reuse is real
&
I fixed trailing columns in make_batch() by setting n_groups = per_col_card^n_cols instead of target_distinct, ensuring group IDs span the full mixed-radix space so every column exercises all its values
@kumarUjjawal