Github user hvanhovell commented on a diff in the pull request:
https://github.com/apache/spark/pull/16818#discussion_r100046288
--- Diff:
sql/core/src/main/scala/org/apache/spark/sql/execution/window/BoundOrdering.scala
---
@@ -25,18 +25,22 @@ import
org.apache.spark.sql.catalyst.expressions.Projection
* Function for comparing boundary values.
*/
private[window] abstract class BoundOrdering {
- def compare(inputRow: InternalRow, inputIndex: Int, outputRow:
InternalRow, outputIndex: Int): Int
+ def compare(
+ inputRow: InternalRow,
+ inputIndex: Long,
+ outputRow: InternalRow,
+ outputIndex: Long): Long
}
/**
* Compare the input index to the bound of the output index.
*/
-private[window] final case class RowBoundOrdering(offset: Int) extends
BoundOrdering {
+private[window] final case class RowBoundOrdering(offset: Long) extends
BoundOrdering {
--- End diff --
If we are going to support 64-bit values in a row frame then we also need
to support a buffer that can store that many rows. `WindowExec` in its current
form assumes that a buffer contains less than `(1 << 31) - 1` values (which is
actually smaller than an 32-bit range can be). I have yet to see a use case
where the buffer needs to be larger.
The current PR does not make all the necessary changes to make `WindowExec`
support a 64-bit buffer (see RowBuffer.size for instance), and I am slightly
worried about overflows. It will also be a daunting task to test this properly
(you will need to create a buffer with more than 2 billion elements). So I
prefer to keep this change local to range frames only.
---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
