fix: decline sort pushdown through SortPreservingMergeExec with fetch (#26162) - #27060

 use crate::utils::{
-    add_sort_above_with_distribution, is_sort, is_sort_preserving_merge, is_union,
-    is_window,
+    add_sort_above_with_distribution, is_sort, is_union, is_window,
 };
@@
-    } else if plan.is::<SortPreservingMergeExec>() && plan.fetch().is_some() {
-        // Why we decline pushdown here:
-        // 1. SPM merges using only its own keys, so pushing additional
-        //    parent keys down cannot be preserved anyway.
-        // 2. The subquery did not explicitly request the parent's sort, so forcing
-        //    it on the entire dataset before a fetch is an unnecessary cost.
-        // 3. Decline pushdown so the parent sort is not dropped and orders the fetched rows.
+    } else if plan.is::<SortPreservingMergeExec>() {
+        // A merge orders rows across partitions only by its own keys, and this
+        // function doesn't rewrite them. Keep the finer parent sort above it.
         Ok(None)
@@
-    } else if is_sort_preserving_merge(plan) {
-        let new_ordering = LexOrdering::from(parent_required.first().clone());
-        let mut spm_eqs = plan.equivalence_properties().clone();
-        let old_ordering = spm_eqs.output_ordering().unwrap();
-        // Sort preserving merge will have new ordering, one requirement above is pushed down to its below.
-        let change = spm_eqs.reorder(new_ordering)?;
-        if !change || spm_eqs.ordering_satisfy(old_ordering)? {
-            // Can push-down through SortPreservingMergeExec, because parent requirement is finer
-            // than SortPreservingMergeExec output ordering.
-            Ok(Some(vec![Some(parent_required)]))
-        } else {
-            // Do not push-down through SortPreservingMergeExec when
-            // ordering requirement invalidates requirement of sort preserving merge exec.
-            Ok(None)
-        }
     } else if let Some(hash_join) = plan.downcast_ref::<HashJoinExec>() {