impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Jacobs (Code Review)" <ger...@cloudera.org>
Subject [Impala-ASF-CR] IMPALA-5137: Support pushing TIMESTAMP predicates to Kudu
Date Wed, 10 May 2017 20:34:35 GMT
Matthew Jacobs has posted comments on this change.

Change subject: IMPALA-5137: Support pushing TIMESTAMP predicates to Kudu
......................................................................


Patch Set 1:

(6 comments)

http://gerrit.cloudera.org:8080/#/c/6789/1/be/src/exprs/timestamp-functions-ir.cc
File be/src/exprs/timestamp-functions-ir.cc:

Line 127:   return (tv.UtcToUnixTimeMicros(&result)) ? BigIntVal(result) : BigIntVal::null();
> i forgot: did we say we need abort_on_error to work for these conversions?
We were going to do that on the read path (and I still have to do that), but that wouldn't
apply here. The errors we're worried about are when unixtimes are outside of Impalas date
range, which can't happen here.


http://gerrit.cloudera.org:8080/#/c/6789/1/be/src/exprs/timestamp-functions.h
File be/src/exprs/timestamp-functions.h:

Line 67:   static BigIntVal Unix(FunctionContext* context, const StringVal& string_val,
> is there any reason why they all have the same name?
I started renaming them but then realized they're aligned with the exposed function names,
i.e. they are all exposed as functions named "unix_timestamp" (obviously with different parameters)


Line 69:   /// Converts 'tv_val' to a unix time_t.
> please separate w/ blank lines, makes it easier to read
Done


http://gerrit.cloudera.org:8080/#/c/6789/1/fe/src/main/java/org/apache/impala/util/KuduUtil.java
File fe/src/main/java/org/apache/impala/util/KuduUtil.java:

Line 212:   
> trailing
Done


http://gerrit.cloudera.org:8080/#/c/6789/1/testdata/workloads/functional-planner/queries/PlannerTest/kudu-selectivity.test
File testdata/workloads/functional-planner/queries/PlannerTest/kudu-selectivity.test:

Line 151: timestamp_col < (seconds_add(cast('9999-12-31 24:59:59' as timestamp), 10))
> doesn't our timestamp literal already give you bounds checking? worth check
Yes it does, it already evaluates to NULL - is that what you meant? I had it here more to
be illustrative, but I can remove if this is confusing.


http://gerrit.cloudera.org:8080/#/c/6789/1/testdata/workloads/functional-query/queries/QueryTest/kudu-scan-node.test
File testdata/workloads/functional-query/queries/QueryTest/kudu-scan-node.test:

Line 92: timestamp_col >= cast('2009-01-01 00:04:00.6' as timestamp)
> add an out-of-bounds literal somewhere
I'll add a separate query since it'll evaluate to NULL


-- 
To view, visit http://gerrit.cloudera.org:8080/6789
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I08b6c8354a408e7beb94c1a135c23722977246ea
Gerrit-PatchSet: 1
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Matthew Jacobs <mj@cloudera.com>
Gerrit-Reviewer: Marcel Kornacker <marcel@cloudera.com>
Gerrit-Reviewer: Matthew Jacobs <mj@cloudera.com>
Gerrit-HasComments: Yes

Mime
View raw message