[ 
https://issues.apache.org/jira/browse/SPARK-27290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803737#comment-16803737
 ] 

Xiaoju Wu commented on SPARK-27290:
-----------------------------------

[~ekoifman] HashAggregate can not benefit from sorted input but SortAggregate 
can. But SortAggregate will require its input sorted by columns of group-by, 
and will enforce the SortExec in the logic of EnsureRequirements. So the 
user-written sort is useless.

> remove unneed sort under Aggregate
> ----------------------------------
>
>                 Key: SPARK-27290
>                 URL: https://issues.apache.org/jira/browse/SPARK-27290
>             Project: Spark
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 2.4.0
>            Reporter: Xiaoju Wu
>            Priority: Minor
>
> I saw some tickets to remove unneeded sort in plan while I think there's 
> another case in which sort is redundant:
> Sort just under an non-orderPreserving node is redundant, for example:
> select count(*) from (select a1 from A order by a2);
> +- Aggregate
>   +- Sort
>      +- FileScan parquet
> But one of the existing test cases is conflict with this example:
> test("sort should not be removed when there is a node which doesn't guarantee 
> any order")
> {   val orderedPlan = testRelation.select('a, 'b).orderBy('a.asc)   val 
> groupedAndResorted = orderedPlan.groupBy('a)(sum('a)).orderBy('a.asc)   val 
> optimized = Optimize.execute(groupedAndResorted.analyze)   val correctAnswer 
> = groupedAndResorted.analyze   comparePlans(optimized, correctAnswer) }
> Why is it designed like this? In my opinion, since Aggregate won't pass up 
> the ordering, the below Sort is useless.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

Reply via email to