JoshRosen commented on code in PR #48661:
URL: https://github.com/apache/spark/pull/48661#discussion_r1821451822


##########
sql/catalyst/src/main/scala/org/apache/spark/sql/internal/SQLConf.scala:
##########
@@ -5207,6 +5207,16 @@ object SQLConf {
     .booleanConf
     .createWithDefault(false)
 
+  val ORDERING_AWARE_LIMIT_OFFSET = 
buildConf("spark.sql.orderingAwareLimitOffset")
+    .internal()
+    .doc("When set to true, a local sort will be inserted between 
GlobalLimitExec and " +
+      "single-partition ShuffleExchangeExec, if the underlying plan produces 
sorted data. " +
+      "This is because shuffle reader in Spark fetches shuffle blocks in a 
random order and " +
+      "can not preserve the data ordering, while LIMIT/OFFSET must preserve 
ordering.")
+    .version("4.0.0")
+    .booleanConf
+    .createWithDefault(true)

Review Comment:
   I see this as more of an "escape hatch" flag in the unlikely scenario that a 
user had a workload which was previously using an incorrect execution plan but 
for which they are okay with re-enabling incorrect behavior for performance 
reasons. 
   
   Given that the originally problematic plan is not used in some of the most 
common SQL scenarios (where, typically, either TakeOrderedAndProjectExec or 
CollectLimitExec are used), I think we might hit some trickiness in how we 
message this in a guide in a way that will be comprehensible to end users: we 
probably don't want to give overly-vague guidance which could be misinterpreted 
as "if you have <generic sounding performance problem> flip this setting", but 
a more narrow and precise description might be similarly unclear to users.
   
   I'm not entirely sure what the right move is here, but I'm provisionally 
okay with tackling the exact wording in a documentation followup if needed.



-- 
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]

Reply via email to