Repository navigation
Conversation
Motivation: approx_distinct rejects Float16/32/64 (also inside dictionary and run-end-encoded types) with a "not implemented" error, but accepted List/Struct/Map/Union containing floats and returned a result, because the support check only looked at the outer type. Approach: Add a recursive contains_float helper (lists, list views, fixed-size lists, maps, structs, unions, dictionaries, REE) and make is_hll_groups_type return false for such types. The scalar accumulator arm for nested types now uses the is_supported_type guard, so nested floats hit the same "not implemented" error as bare floats; the groups accumulator check is consistent through is_hll_groups_type. Impact: queries over nested-float columns that previously returned a count now return the not-implemented error, matching bare floats. Validation: - cargo test -p datafusion-functions-aggregate approx_distinct (16 passed; includes new nested_float_unsupported unit test) - cargo test --profile ci -p datafusion-sqllogictest --test sqllogictests -- aggregate new approx_distinct cases in aggregate.slt pass. Other failures in that run (e.g. bit_xor, aggregate_skip_partial) also occur on the unmodified base and are unrelated. - cargo fmt --all; cargo clippy -p datafusion-functions-aggregate --all-targets -- -D warnings: clean. I did not run the full extended workspace test suite. Report: apache#26985 Signed-off-by: Pujitha Paladugu <[email protected]> Assisted-by: claude-sonnet-5-5 (via Claude Code)
…lper Signed-off-by: Pujitha Paladugu <[email protected]>
|
Both of these should already be in the branch's latest commit (3245e8b), in case you were looking at the first commit. |
There was a problem hiding this comment.
Thanks for for working on this. Overall it does the right thing. A few things before it can go in:
- The new helper function already exists.
contains_floatdoes the same job asdatafusion_common::float_semantics::has_float_leaf, which is used in other places. - Test with a list inside a list would show that floats are found at any depth.
| use std::hash::BuildHasher; | ||
|
|
||
| #[test] | ||
| fn nested_float_unsupported() { |
There was a problem hiding this comment.
I think the slt tests are sufficient. we don't need this test.
| /// [`HllGroupsAccumulator`]. The fixed-domain types (booleans / small ints) and | ||
| /// `Null` fall back to the per-group [`Accumulator`] path. | ||
| fn is_hll_groups_type(data_type: &DataType) -> bool { | ||
| if has_float_leaf(data_type) { |
There was a problem hiding this comment.
This should move up to is_supported_type, this is not only group related.
| || is_hll_groups_type(value_type) | ||
| } | ||
|
|
||
| fn encoded_value_type(data_type: &DataType) -> &DataType { |
There was a problem hiding this comment.
If we move has_float_leaf into is_supported_type we can get rid of encoded_value_type completely.
…t test Signed-off-by: Pujitha Paladugu <[email protected]>
Which issue does this PR close?
approx_distinctrejects floats, but accepts containers of them #26985.Rationale for this change
approx_distinctrejects floats (bare, or inside dictionary/REE) with a "not implemented" error, but silently accepted lists, structs and maps containing floats.What changes are included in this PR?
A recursive
contains_floatcheck inis_hll_groups_type, and the nested-type accumulator arm now uses theis_supported_typeguard, so nested floats get the same not-implemented error.What is the testing strategy for this PR?
New unit test
nested_float_unsupportedand new sqllogictest cases inaggregate.slt(List/Struct/Map, with and without GROUP BY). Unit tests and the new slt cases pass; other pre-existing failures in the aggregate slt run also occur on the base. Full extended suite not run.Are there any user-facing changes?
Queries over nested-float columns that previously returned a count now return the not-implemented error, consistent with bare floats.