allisonwang-db commented on a change in pull request #30659:
URL: https://github.com/apache/spark/pull/30659#discussion_r544578497



##########
File path: 
sql/core/src/main/scala/org/apache/spark/sql/execution/RemoveRedundantProjects.scala
##########
@@ -61,15 +63,24 @@ object RemoveRedundantProjects extends Rule[SparkPlan] {
         val keepOrdering = a.aggregateExpressions
           .exists(ae => ae.mode.equals(Final) || ae.mode.equals(PartialMerge))
         a.mapChildren(removeProject(_, keepOrdering))
-      // GenerateExec requires column ordering since it binds input rows 
directly with its
-      // requiredChildOutput without using child's output schema.
-      case g: GenerateExec => g.mapChildren(removeProject(_, true))
-      // JoinExec ordering requirement will inherit from its parent. If there 
is no ProjectExec in
-      // its ancestors, JoinExec should require output columns to be ordered.
-      case o => o.mapChildren(removeProject(_, requireOrdering))
+      case p if canPassThrough(p) => p.mapChildren(removeProject(_, 
requireOrdering))
+      case o => o.mapChildren(removeProject(_, requireOrdering = true))
     }
   }
 
+  /**
+   * Check if the given node can pass the ordering requirement from its parent.
+   */
+  private def canPassThrough(plan: SparkPlan): Boolean = plan match {
+    case _: FilterExec => true
+    // JoinExec ordering requirement should inherit from its parent. If there 
is no ProjectExec in
+    // its ancestors, JoinExec should require output columns to be ordered, 
and vice versa.
+    case _: BaseJoinExec => true
+    case _: WindowExec => true
+    case _: ExpandExec => true

Review comment:
       These operators are observed from the TPC-DS plans. Logically speaking, 
the ordering requirements can always be passed through from the parents to the 
children. The reason why some operators' column orders cannot be switched is 
that their execution logic assumes the columns are under a certain order. It is 
difficult to test whether such assumption exists for every single physical 
operator unless a redundant project naturally exists in a plan (or we 
artificially inject a redundant project which is less desirable and doesn't 
seem to be necessary). So this is a list that includes the cases we are seeing 
right now, and if there are more cases discovered in the future, we can always 
add them here.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to