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]
