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-4571: InList predicates not being pushed to Kudu scans
Date Fri, 02 Dec 2016 22:30:45 GMT
Matthew Jacobs has posted comments on this change.

Change subject: IMPALA-4571: InList predicates not being pushed to Kudu scans
......................................................................


Patch Set 2:

(12 comments)

http://gerrit.cloudera.org:8080/#/c/5316/2//COMMIT_MSG
Commit Message:

Line 7: IMPALA-4571: InList predicates not being pushed to Kudu scans
> Push IN predicates to Kudu.
Done


Line 12: An InPredicate can be pushed to the scan if:
> might be more concise to mention that only these predicates are supported:
Done


Line 13: 1) It has a list of values (i.e. not a subquery)
> list of literal values
Done


Line 17:    exactly.
> one requirement missing from this list is is that all values in the IN list
Done


http://gerrit.cloudera.org:8080/#/c/5316/2/fe/src/main/java/org/apache/impala/analysis/InPredicate.java
File fe/src/main/java/org/apache/impala/analysis/InPredicate.java:

Line 54:     Preconditions.checkArgument(isAnalyzed_);
> Not really a requirement, why not just inline this one-line function at the
I'll just remove both of these, you were right I don't need hasValuesList() either


http://gerrit.cloudera.org:8080/#/c/5316/2/fe/src/main/java/org/apache/impala/planner/KuduScanNode.java
File fe/src/main/java/org/apache/impala/planner/KuduScanNode.java:

Line 366:     if (predicate.isNotIn() || !predicate.hasValuesList()) return false;
> the hasValuesList() check seems unecessary, it is already covered by checki
Done


Line 371:     PrimitiveType type = ref.getType().getPrimitiveType();
> unused?
this is passed into the fn on line 380


Line 397:   private static Object getKuduInListValue(PrimitiveType type, Expr e) {
> Move to LiteralExpr.valueAsObject() or something like that?
That's a good idea, though here I can better handle the types Kudu doesn't support. If I put
this in LiteralExpr I'd prob return all types. Here I'd still have to check which types should
be supported or not, i.e. I still need to branch on the types. Also, if I move it we also
need to make sure we do the right thing for Decimal and Timestamp, then returning Object seems
more questionable. Would you mind if I keep it here and more specific for Kudu right now?


Line 399:     if (type != e.getType().getPrimitiveType()) return null;
> This is a post-condition of InPredicate.analyze(), you don't need to check 
Done


Line 409:       default: return null;
> It sounds like a bug if we hit this case because it implies we have a SlotR
Hm I think you're right, I guess I'll make it throw here


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

Line 108: double_col in (0.0) and
> string_col?
Done


Line 117: double_col in (cast('inf' as double))
> * add a NOT IN predicate
Done


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

Gerrit-MessageType: comment
Gerrit-Change-Id: I8988d4819d20d467b48e286917e347ca00f60cf0
Gerrit-PatchSet: 2
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Matthew Jacobs <mj@cloudera.com>
Gerrit-Reviewer: Alex Behm <alex.behm@cloudera.com>
Gerrit-Reviewer: Matthew Jacobs <mj@cloudera.com>
Gerrit-HasComments: Yes

Mime
View raw message