yinchuanwang commented on a change in pull request #2420:
URL: https://github.com/apache/calcite/pull/2420#discussion_r647115126
##########
File path:
elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/PredicateAnalyzer.java
##########
@@ -179,6 +186,13 @@ private static boolean supportedRexCall(RexCall call) {
default:
return false;
}
+ case INTERNAL:
+ switch (call.getKind()) {
+ case SEARCH:
+ return true;
+ default:
+ return false;
Review comment:
The 'IN' clause is simplified from 'OR' into 'SEARCH'. Please refer to
the method simplifyOrs(line 1867) of RexSimplify.java for the details.
Below is the logical plan change history of the test sql 'select count(*)
from view where cat1 in ('a', 'b')'
Original:
`LogicalAggregate(group=[{}], EXPR$0=[COUNT()]): rowcount = 1.0, cumulative
cost = {136.125 rows, 810.1 cpu, 0.0 io}, id = 14
LogicalFilter(condition=[OR(=($0, 'a'), =($0, 'b'))]): rowcount = 25.0,
cumulative cost = {135.0 rows, 810.1 cpu, 0.0 io}, id = 12
LogicalProject(cat1=[ITEM($0, 'cat1')], cat2=[ITEM($0, 'cat2')],
cat3=[ITEM($0, 'cat3')], cat4=[ITEM($0, 'cat4')], cat5=[ITEM($0, 'cat5')],
val1=[ITEM($0, 'val1')], val2=[ITEM($0, 'val2')]): rowcount = 100.0, cumulative
cost = {110.0 rows, 710.1 cpu, 0.0 io}, id = 11
ElasticsearchTableScan(table=[[elastic, aggs]]): rowcount = 100.0,
cumulative cost = {10.0 rows, 10.100000000000001 cpu, 0.0 io}, id = 10`
Simplified:
`LogicalAggregate(group=[{}], EXPR$0=[COUNT()]): rowcount = 2.5, cumulative
cost = {2.8125 rows, 0.0 cpu, 0.0 io}, id = 32
LogicalFilter(subset=[rel#31:RelSubset#2.NONE.[]], condition=[SEARCH($0,
Sarg['a', 'b']:CHAR(1))]): rowcount = 25.0, cumulative cost = {25.0 rows, 100.0
cpu, 0.0 io}, id = 30
LogicalProject(subset=[rel#29:RelSubset#1.NONE.[]], cat1=[ITEM($0,
'cat1')]): rowcount = 100.0, cumulative cost = {100.0 rows, 100.0 cpu, 0.0 io},
id = 28
ElasticsearchTableScan(subset=[rel#27:RelSubset#0.ELASTICSEARCH.[]],
table=[[elastic, aggs]]): rowcount = 100.0, cumulative cost = {10.0 rows,
10.100000000000001 cpu, 0.0 io}, id = 10
`
Best exp by the planner:
`ElasticsearchToEnumerableConverter: rowcount = 1.0, cumulative cost =
{12.7125 rows, 20.200000000000003 cpu, 0.0 io}, id = 84
ElasticsearchAggregate(group=[{}], EXPR$0=[COUNT()]): rowcount = 1.0,
cumulative cost = {12.6125 rows, 20.1 cpu, 0.0 io}, id = 83
ElasticsearchFilter(condition=[SEARCH(ITEM($0, 'cat1'), Sarg['a',
'b']:CHAR(1))]): rowcount = 25.0, cumulative cost = {12.5 rows, 20.1 cpu, 0.0
io}, id = 82
ElasticsearchTableScan(table=[[elastic, aggs]]): rowcount = 100.0,
cumulative cost = {10.0 rows, 10.100000000000001 cpu, 0.0 io}, id = 10`
The reason why only return true for 'SEARCH' is to minimize the impact of
this change, so the other cases can go the old ways.
Actually there are three subtypes of SEARCH based on the included Sarg :
1) Sarg isPoints. (map to In ('a', 'b', 'c'))
2) Sarg isComplementedPoints. (map to Not in ('a', 'b', 'c'))
3) Sarg is real Range set. (map to (f1 > 10 and f1 < 20) or (f1 > 30 and f1
< 40)).
The 1) and 2) cases can be translated to terms Query.
And the 3) case should be translated to range Query.
Currently only the 1) and 2) cases are supported, so I added a more strict
filter condition.
The future work we can do is to support the 3) case to translate it to range
Query of ES.
--
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]
