Repository navigation
Sort key over get_field(named_struct(...), f) is evaluated against the materialized struct instead of the base column #22487
Description
Follow-up from #22239. For a query that sorts by a struct field, where the table is WITH ORDER (a + b) so a SortExec is genuinely required:
EXPLAIN SELECT named_struct('a', a, 'b', b) AS s FROM ordered ORDER BY s['a'];Plan before #22239 — get_field sort key extracted into a flat scan column, recovery projection hides it:
01)ProjectionExec: expr=[s@0 as s]
02)--SortExec: expr=[__datafusion_extracted_1@1 ASC NULLS LAST], preserve_partitioning=[false]
03)----DataSourceExec: projection=[named_struct(a, a@0, b, b@1) as s, get_field(named_struct(a, a@0, b, b@1), a) as __datafusion_extracted_1], ...
Plan after #22239 — simpler, but the sort key is a struct-field extraction over the materialized struct:
01)SortExec: expr=[get_field(s@0, a) ASC NULLS LAST], preserve_partitioning=[false]
02)--DataSourceExec: projection=[named_struct(a, a@0, b, b@1) as s], ...
Ideal plan — sort on the base column, build the struct afterward:
01)ProjectionExec: expr=[named_struct(a, a@0, b, b@1) as s]
02)--SortExec: expr=[a@0 ASC NULLS LAST]
03)----DataSourceExec: projection=[a, b]
Activity
Brijesh-Thakkar commentedon May 29, 2026
@adriangb Heyy are u working on this one
If not then I am ready to contribute by trying to solve it
adriangb commentedon May 30, 2026
I'm not sure this is even worth tackling to be honest. I think it's worth thinking critically (or running some benchmarks) to see if there's a provable case where we could improve our behavior.