impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Jacobs (Code Review)" <>
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:

Commit Message:

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

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

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

Line 17:    exactly.
> one requirement missing from this list is is that all values in the IN list
File fe/src/main/java/org/apache/impala/analysis/

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
File fe/src/main/java/org/apache/impala/planner/

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

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 

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
File testdata/workloads/functional-planner/queries/PlannerTest/kudu-selectivity.test:

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

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

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: I8988d4819d20d467b48e286917e347ca00f60cf0
Gerrit-PatchSet: 2
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Matthew Jacobs <>
Gerrit-Reviewer: Alex Behm <>
Gerrit-Reviewer: Matthew Jacobs <>
Gerrit-HasComments: Yes

View raw message