cloud-fan commented on a change in pull request #35710:
URL: https://github.com/apache/spark/pull/35710#discussion_r823874415
##########
File path:
sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/v2/V2ScanRelationPushDown.scala
##########
@@ -362,7 +362,11 @@ object V2ScanRelationPushDown extends Rule[LogicalPlan]
with PredicateHelper {
if (topNPushed) {
sHolder.pushedLimit = Some(limit)
sHolder.sortOrders = orders
- operation
+ sHolder.builder match {
+ case s: SupportsPushDownTopN if s.supportCompleteSortPushDown() =>
+ operation
+ case _ => s
Review comment:
This makes the top N pushdown look like a hint: we notify the source
that a top N is needed, but the Spark query plan is not changed.
This is definitely not optimal: Spark still does a sort, and probably a
shuffle if the limit is large. Performance-wise, I think it's the same as
pushing down a limit. How about a simpler approach: if we can't push down top
N, we just push down limit without changing the plan. Then we don't need to
change DS v2 APIs.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
