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
fix(sort-pushdown): drop runtime row-group reorder hints on Inexact→Exact upgrade
When `try_pushdown_sort` upgrades the `Inexact` result back to `Exact`
(post-sort file groups non-overlapping + declared ordering re-validates),
the `SortExec` is removed. But the source rebuilt from the `Inexact` result
still carried `sort_order_for_reorder` / `reverse_row_groups`, so the parquet
opener kept reordering row groups at runtime.
With the `SortExec` gone, that runtime reorder is no longer a harmless
optimisation — it is load-bearing for correctness, and it is wrong for DESC
requests. The opener sorts row groups ASC-by-min and then `reverse()`s them;
two row groups within a single file that share the same `min` but differ in
`max` get mis-ordered by the reverse. Example: a file declared `WITH ORDER
(id DESC)` containing `[10,8,8,8]` whose row groups are `[10,8]` and `[8,8]`
(both min 8) streams as `8,8,10,8`. Previously the `SortExec` re-sorted that;
once eliminated, the wrong order is the final result.
Because the upgrade only fires when each file's declared ordering re-validates
against the non-overlapping post-sort file groups, reading the files in their
natural (declared-sorted) order already yields the requested ordering — no
runtime reorder is needed. Restore the original, hint-free source on upgrade,
matching the `Unsupported → Exact` path which also reads files naturally.
Existing tests 4.1 / 6.1 / 8.1 / G.1 / G.2 lose the now-absent
`sort_order_for_reorder` / `reverse_row_groups` from their `DataSourceExec`
plans; data results are unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments