[jira] [Resolved] (IMPALA-14324) Calcite planner: Wrong cardinality shown with is_not_null predicate in scan node

["Steve Carlin (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IMPALA-14324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Carlin resolved IMPALA-14324.
-----------------------------------
      Assignee: Steve Carlin
    Resolution: Fixed

> Calcite planner: Wrong cardinality shown with is_not_null predicate in scan node
> --------------------------------------------------------------------------------
>
>                 Key: IMPALA-14324
>                 URL: https://issues.apache.org/jira/browse/IMPALA-14324
>             Project: IMPALA
>          Issue Type: Sub-task
>            Reporter: Steve Carlin
>            Assignee: Steve Carlin
>            Priority: Major
>
> Taken from review: [https://gerrit.cloudera.org/#/c/22870]
> When running  TpcdsCpuCostPlannerTest under the java/calcite-planner directory, the cardinality for store_returns is showing up as: (filtered from 86.40M)
> It should be 864M.  The reason it is only .1 times the size is because the is_not_null pred filter selectivity is being treated as filtering out 90% of the rows.  This is due to the Planner::computeSelectivities method using the following lines:
> {code:java}
>     if (selectivities.size() != conjunctSize) {
>       // Some conjuncts have no estimated selectivity. Use a single default
>       // representative selectivity for all those conjuncts.
>       selectivities.add(Expr.DEFAULT_SELECTIVITY);
>     }{code}
> We need the getSelectivity for the "is not null" predicate expression to return the right result.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)