Github user JoshRosen commented on a diff in the pull request:
https://github.com/apache/spark/pull/9383#discussion_r43785059
--- Diff:
sql/core/src/main/scala/org/apache/spark/sql/execution/aggregate/TungstenAggregationIterator.scala
---
@@ -762,15 +679,7 @@ class TungstenAggregationIterator(
/**
* Start processing input rows.
*/
- testFallbackStartsAt match {
- case None =>
- processInputs()
- case Some(fallbackStartsAt) =>
- // This is the testing path. processInputsWithControlledFallback is
same as processInputs
- // except that it switches to sort-based aggregation after
`fallbackStartsAt` input rows
- // have been processed.
- processInputsWithControlledFallback(fallbackStartsAt)
- }
+ processInputs(testFallbackStartsAt.getOrElse(Int.MaxValue))
--- End diff --
I guess it isn't a huge deal to have a really high limit here, as opposed
to no limit, because the cost of spilling after processing a couple of billion
rows will be fairly minimal; either we would have spilled earlier or we're
experiencing a huge reduction factor, so the cost of spilling should be minimal.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
