[jira] [Commented] (HIVE-19097) related equals and in operators may cause inaccurate stats estimations

["Zoltan Haindrich (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HIVE-19097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16511246#comment-16511246 ] 

Zoltan Haindrich commented on HIVE-19097:
-----------------------------------------

I've just checked it out; and now when the IN operators are opened; and if I use a 1.17 calcite snapshot; further optimizations are happening (as they should)...however, opening these INs has a negative effect on other things; like on [HIVE-19460-in_estimator] - which after opening the ORs could not do anything...

I see the following options right now:

# do a min/max predicate pruning inside a calcite rule; that will easily do what [HIVE-19460-in_estimator] have done ... but it needs the INs to be open(this patch)
# set HIVEPOINTLOOKUPOPTIMIZERMIN to a smaller value; like 3 - I think this would also enable [HIVE-19460-in_estimator] to do better work
# add a similar logic as [HIVE-19460-in_estimator] to the stats rules for binary operators (<,>,=,..)

There might be other options which I've not found yet....I think 1. would be probably harder to achieve - or at least I'm not entirely sure how to get started with it :) 
I think 2+3 would be good for now...

[~jcamachorodriguez], [~ashutoshc]: what do you think about it?


> related equals and in operators may cause inaccurate stats estimations
> ----------------------------------------------------------------------
>
>                 Key: HIVE-19097
>                 URL: https://issues.apache.org/jira/browse/HIVE-19097
>             Project: Hive
>          Issue Type: Bug
>            Reporter: Zoltan Haindrich
>            Assignee: Zoltan Haindrich
>            Priority: Major
>         Attachments: HIVE-19097.01.patch, HIVE-19097.partial.patch
>
>
> tpcds#74 is optimized in a way that for date_dim the condition contains IN and = for the same column
> {code:java}
> |             Map Operator Tree:                     |
> |                 TableScan                          |
> |                   alias: date_dim                  |
> |                   filterExpr: (((d_year) IN (2001, 2002) and (d_year = 2002) and d_date_sk is not null) or ((d_year) IN (2001, 2002) and (d_year = 2001) and d_date_sk is not null)) (type: boolean) |
> |                   Statistics: Num rows: 73049 Data size: 876588 Basic stats: COMPLETE Column stats: COMPLETE |
> |                   Filter Operator                  |
> |                     predicate: ((d_year) IN (2001, 2002) and (d_year = 2002) and d_date_sk is not null) (type: boolean) |
> |                     Statistics: Num rows: 4 Data size: 48 Basic stats: COMPLETE Column stats: COMPLETE |
> {code}
> the "real" row count will be 365
> for separate {{IN}} and {{=}} the estimation is very good; but if both are present it becomes (very) underestimated.
> {code:java}
> set hive.query.results.cache.enabled=false;
> drop table if exists t1;
> drop table if exists t8;
> create table t1 (a integer,b integer);
> create table t8 like t1;
> insert into t1 values (1,1),(2,2),(3,3),(4,4),(5,5);
> insert into t8
> select * from t1 union all select * from t1 union all select * from t1 union all select * from t1 union all
> select * from t1 union all select * from t1 union all select * from t1 union all select * from t1
> ;
> analyze table t1 compute statistics for columns;
> analyze table t8 compute statistics for columns;
> explain analyze select sum(a) from t8 where b in (2,3) group by b;
> explain analyze select sum(a) from t8 where b=2 group by b;
> explain analyze select sum(a) from t1 where b in (2,3) and b=2 group by b;
> explain analyze select sum(a) from t8 where b in (2,3) and b=2 group by b;
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)