abstractdog edited a comment on pull request #1950:
URL: https://github.com/apache/hive/pull/1950#issuecomment-775826706
> Hey @abstractdog change makes sense to me -- question is how often do we
really call the TsBoundary Scanner during range computation? Is the test
representative of the scanario?
>
> Would the optimization make sense to other types as well e.g.,
TimestampLocalTZ or Date?
this could be heavy code path yes, as in case range based windows, every row
needs to be checked:
```
at
org.apache.hadoop.hive.common.type.Timestamp.setTimeInSeconds(Timestamp.java:133)
at
org.apache.hadoop.hive.serde2.io.TimestampWritableV2.populateTimestamp(TimestampWritableV2.java:401)
at
org.apache.hadoop.hive.serde2.io.TimestampWritableV2.getTimestamp(TimestampWritableV2.java:210)
at
org.apache.hadoop.hive.serde2.objectinspector.primitive.PrimitiveObjectInspectorUtils.getTimestamp(PrimitiveObjectInspectorUtils.java:1239)
at
org.apache.hadoop.hive.serde2.objectinspector.primitive.PrimitiveObjectInspectorUtils.getTimestamp(PrimitiveObjectInspectorUtils.java:1181)
at
org.apache.hadoop.hive.ql.udf.ptf.TimestampValueBoundaryScanner.isEqual(ValueBoundaryScanner.java:848)
at
org.apache.hadoop.hive.ql.udf.ptf.SingleValueBoundaryScanner.computeEndCurrentRow(ValueBoundaryScanner.java:593)
at
org.apache.hadoop.hive.ql.udf.ptf.SingleValueBoundaryScanner.computeEnd(ValueBoundaryScanner.java:530)
at
org.apache.hadoop.hive.ql.udf.ptf.BasePartitionEvaluator.getRange(BasePartitionEvaluator.java:273)
at
org.apache.hadoop.hive.ql.udf.ptf.BasePartitionEvaluator.iterate(BasePartitionEvaluator.java:219)
at
org.apache.hadoop.hive.ql.udf.ptf.WindowingTableFunction.evaluateWindowFunction(WindowingTableFunction.java:147)
at
org.apache.hadoop.hive.ql.udf.ptf.WindowingTableFunction.access$100(WindowingTableFunction.java:61)
at
org.apache.hadoop.hive.ql.udf.ptf.WindowingTableFunction$WindowingIterator.next(WindowingTableFunction.java:755)
at
org.apache.hadoop.hive.ql.exec.PTFOperator$PTFInvocation.finishPartition(PTFOperator.java:373)
at
org.apache.hadoop.hive.ql.exec.PTFOperator.closeOp(PTFOperator.java:104)
at org.apache.hadoop.hive.ql.exec.Operator.close(Operator.java:732)
at org.apache.hadoop.hive.ql.exec.Operator.close(Operator.java:756)
at
org.apache.hadoop.hive.ql.exec.tez.ReduceRecordProcessor.close(ReduceRecordProcessor.java:383)
at
org.apache.hadoop.hive.ql.exec.tez.TezProcessor.initializeAndRunProcessor(TezProcessor.java:284)
at
org.apache.hadoop.hive.ql.exec.tez.TezProcessor.run(TezProcessor.java:250)
```
looks like a good idea to check other types' compareTo shortcuts
TimestampLocalTZWritable doesn't seem to be subject to the same optimization
as its compareTo will do heavy operations anyway (getTimestampTZ ->
populateTimestampTZ)
```
@Override
public int compareTo(TimestampLocalTZWritable o) {
return getTimestampTZ().compareTo(o.getTimestampTZ());
}
```
we'll have to find out if this can be simplified in the same way (maybe
another jira, fyi: @rbalamohan if you're aware of this), so compareTo should
use bytes if bytes are present, similarly to TimestampWritableV2:
```
public int compareTo(TimestampWritableV2 t) {
checkBytes();
long s1 = this.getSeconds();
...
```
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
