Add support for dictionary for approx_distinct

[mkleen]

Which issue does this PR close?

• Relates to Support more types for approx_distinct function #22989 but does not close it. More types are coming.

Rationale for this change

• Support the Arrow type Dictionary for approx_distinct

What changes are included in this PR?

• Enable HLLAccumulator and HllGroupsAccumulator to support Dictionary
• Tests

Are these changes tested?

Yes

Are there any user-facing changes?

Yes, approx_distinct supports now Dictionary but no breaking changes.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.58%. Comparing base (5980374) to head (9f9aa29).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #24646      +/-   ##
==========================================
- Coverage   81.63%   81.58%   -0.06%     
==========================================
  Files        1123     1123              
  Lines      410298   410674     +376     
  Branches   410298   410674     +376     
==========================================
+ Hits       334965   335040      +75     
- Misses      55642    55916     +274     
- Partials    19691    19718      +27     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mkleen]

@Jefffrey

[kumarUjjawal]

Thank you @mkleen this looks good overall. I had two comments please check.

[kumarUjjawal]

Would it work to match on the value type instead, so a dictionary is supported exactly when its values would be? Something like DataType::Dictionary(_, value_type)

[mkleen]

Good point. Floats will be unsupported see #23084, So we should exclude them in all container types.

[Jefffrey]

i still feel we can support floats here if we already support it in regular distinct count 🤔

also for reference seems duckdb supports:

memory D select approx_count_distinct(a) from values (1.5::double), (1.5), ('nan'::double), (null), (0) t(a);
┌──────────────────────────┐
│ approx_count_distinct(a) │
│          int64           │
├──────────────────────────┤
│                        3 │
└──────────────────────────┘

[mkleen]

Ok makes sense. I will look into this.

[kumarUjjawal]

The unconditional arm accepts dictionaries whose value type remains intentionally unsupported.

For example, Dictionary(Int32, Float64) reaches HLLAccumulator, whose hashing path supports floats, although plain Float64 returns NotImplemented. Grouped aggregation also bypasses the restriction through GroupsAccumulatorAdapter.

We can validate the value type recursively with a shared supported-type predicate and add a negative float-dictionary regression.

[kumarUjjawal]

would it make sense to have both dictionary arms on the value type, so Dictionary(_, value_type) is accepted only when is_hll_groups_type(value_type) is true?

[Jefffrey]

this is a good point

[mkleen]

That's a good idea. Thank you!

[Rich-T-kid]

you beat me to it #24731 😆.

[kumarUjjawal]

Recursing here returns false for dictionaries containing Boolean, small integers, or Null, because those plain types use specialized scalar accumulators. The grouped executor then creates one HLLAccumulator per group through GroupsAccumulatorAdapter; each accumulator embeds a 16 KiB sketch. A dictionary-encoded Boolean with 100,000 groups can therefore consume about 1.5 GiB for sketches alone. Please route every supported dictionary through HllGroupsAccumulator, or provide a compact dictionary-aware fallback, and add a path-sensitive regression for a fixed-domain dictionary.

[kumarUjjawal]

The unconditional arm accepts dictionaries whose value type remains intentionally unsupported.

For example, Dictionary(Int32, Float64) reaches HLLAccumulator, whose hashing path supports floats, although plain Float64 returns NotImplemented. Grouped aggregation also bypasses the restriction through GroupsAccumulatorAdapter.

We can validate the value type recursively with a shared supported-type predicate and add a negative float-dictionary regression.