You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Sort options for DataType::Dictionary is incorrect #4649
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
(This section helps Arrow developers understand the context and why for this feature, in addition to the what)
Looks like when the DataType is Dictionary, it always reset the Nulls First settings and ignore the sort option from the query engine. This will generate wrong sort result. I will add a UT to reproduce the issue.
There is, however, a known issue with lexsort's handling of nested nulls in dictionaries - apache/arrow-rs#2687 although again it should be noted that arrow-rs will not generate such arrays naturally.
I tried to reproduce this like so but was not able to. i dont think any tests were ever added for this - do we think adding some SLT tests for example here with these cases would be helpful to ensure no regressions and proper integration with arrow kernel? Or is it okay to just close this?
DataFusion CLI v55.1.0
> CREATE TABLE t AS
SELECT arrow_cast(v, 'Dictionary(Int32, Utf8)') AS d
FROM (VALUES ('b'), (NULL), ('a'), ('c'), (NULL)) AS x(v);
0 row(s) fetched.
Elapsed 0.011 seconds.
> SELECT arrow_typeof(d) FROM t LIMIT 1;
+-------------------------+
| arrow_typeof(t.d) |
+-------------------------+
| Dictionary(Int32, Utf8) |
+-------------------------+
1 row(s) fetched.
Elapsed 0.033 seconds.
> SELECT d FROM t ORDER BY d ASC NULLS FIRST;
+------+
| d |
+------+
| NULL |
| NULL |
| a |
| b |
| c |
+------+
5 row(s) fetched.
Elapsed 0.016 seconds.
> SELECT d FROM t ORDER BY d ASC NULLS LAST;
+------+
| d |
+------+
| a |
| b |
| c |
| NULL |
| NULL |
+------+
5 row(s) fetched.
Elapsed 0.001 seconds.
> SELECT d FROM t ORDER BY d DESC NULLS FIRST;
+------+
| d |
+------+
| NULL |
| NULL |
| c |
| b |
| a |
+------+
5 row(s) fetched.
Elapsed 0.001 seconds.
> SELECT d FROM t ORDER BY d DESC NULLS LAST;
+------+
| d |
+------+
| c |
| b |
| a |
| NULL |
| NULL |
+------+
5 row(s) fetched.
Elapsed 0.001 seconds.
@matthewmturner@alamb It may have been fixed by the arrow-rs dictionary sort rewrite (apache/arrow-rs#4605). arrow-rs now tests null dictionary values with all asc/desc and nulls first/last combinations (test_sort_int8_dicts), so I think it's fine to close.
I tried to reproduce this like so but was not able to. i dont think any tests were ever added for this - do we think adding some SLT tests for example here with these cases would be helpful to ensure no regressions and proper integration with arrow kernel? Or is it okay to just close this?
It wouldn't hurn to add SLT to be sure, but I also think closing is fine
Activity
tustvold commentedon Dec 16, 2022
The logic you link to is fairly well tested - https://github.com/apache/arrow-rs/blob/a0a5880665b1836890f6843b6b8772d81c463351/arrow-ord/src/sort.rs#L2998
There is, however, a known issue with lexsort's handling of nested nulls in dictionaries - apache/arrow-rs#2687 although again it should be noted that arrow-rs will not generate such arrays naturally.
matthewmturner commentedon Oct 27, 2026
I tried to reproduce this like so but was not able to. i dont think any tests were ever added for this - do we think adding some SLT tests for example here with these cases would be helpful to ensure no regressions and proper integration with arrow kernel? Or is it okay to just close this?
matthewmturner commentedon Oct 27, 2026
@xudong963 @zhuqi-lucas what do you think?
zhuqi-lucas commentedon Oct 27, 2026
@matthewmturner @alamb It may have been fixed by the arrow-rs dictionary sort rewrite (apache/arrow-rs#4605). arrow-rs now tests null dictionary values with all asc/desc and nulls first/last combinations (
test_sort_int8_dicts), so I think it's fine to close.alamb commentedon Oct 27, 2026
It wouldn't hurn to add SLT to be sure, but I also think closing is fine
zhuqi-lucas commentedon Oct 27, 2026
+1 it's fine to adding the SLT cases, they're cheap and also cover the DataFusion integration.
matthewmturner commentedon Oct 27, 2026
Okay will work on that
matthewmturner commentedon Oct 27, 2026
Here we go
Ordering tests on dictionary types (apache#26834)