You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Leonid Chistov (Jira)" <ji...@apache.org> on 2023/04/12 13:35:00 UTC

[jira] [Comment Edited] (CALCITE-5639) RexSimplify should remove IS NOT NULL check when LIKE comparison is present

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

Leonid Chistov edited comment on CALCITE-5639 at 4/12/23 1:34 PM:
------------------------------------------------------------------

[~julianhyde] 

I can try to do that.

After looking on the  {{class Strong}} I think that there is some confusion between class JavaDoc and JavaDoc (and behavior) of actual implementation:
 * Class JavaDoc says "A predicate is strong (or null-rejecting) if it is UNKNOWN if *any* of its inputs is UNKNOWN"
 * {{isStrong}} method JavaDoc says "Returns whether a given expression is strong."
 * {{isNull}} method JavaDoc says "Returns whether the analyzed expression will definitely return null if *all* of a given set of input columns are null"

{{isNull}} method is used by {{isStrong}} method to do the job and it seems that we silently change {{strongness}} definition.

For example, if we have an expression COALESCE(A, B), it will be NULL if *all* inputs are NULL, but it is not true to say that it will be NULL, if *any* of inputs is null.

And it seems that JoinDeriveIsNotNullFilterRule optimization rule relies on *any* style of _strongness_ definition (which does not correspond to real behavior) and thus may lead to wrong result.

So, it seems that some other Jira issues need to be created to clarify {{Strong class }} behavior.

I am not sure yet, whether fix for current issue will be dependent on this clarification or not.


was (Author: JIRAUSER298393):
[~julianhyde] 

I can try to do that.

After looking on the  {{class Strong}} I think that there is some confusion between class JavaDoc and JavaDoc (and behavior) of actual implementation:
 * Class JavaDoc says "A predicate is strong (or null-rejecting) if it is UNKNOWN if *any* of its inputs is UNKNOWN"
 * {{isStrong}} method JavaDoc says "Returns whether a given expression is strong."
 * {{isNull}} method JavaDoc says "Returns whether the analyzed expression will definitely return null if *all* of a given set of input columns are null"

{\{isNull}} method is used by {{isStrong}} method to do the job and it seems that we silently change {{strongness}} definition.

For example, if we have an expression COALESCE(A, B), it will be NULL if *all* inputs are NULL, but it is not true to say that it will be NULL, if *any* of inputs are null.

And it seems that JoinDeriveIsNotNullFilterRule optimization rule relies on *any* style of _strongness_ definition (which does not correspond to real behavior) and thus may lead to wrong result.

So, it seems that some other Jira issues need to be created to clarify {{Strong class }} behavior.

I am not sure yet, whether fix for current issue will be dependent on this clarification or not.

> RexSimplify should remove IS NOT NULL check when LIKE comparison is present
> ---------------------------------------------------------------------------
>
>                 Key: CALCITE-5639
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5639
>             Project: Calcite
>          Issue Type: Bug
>    Affects Versions: 1.34.0
>            Reporter: Leonid Chistov
>            Assignee: Leonid Chistov
>            Priority: Minor
>              Labels: pull-request-available
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Consider query like
> {code:java}
> select r_reason_desc from reason
> where r_reason_desc is not null and r_reason_desc like '%child%' 
> {code}
> where "r_reason_desc" is a nullable field.
> When RexSimplify::simplifyFilterPredicates is called on that conjunction of expressions, expression is not simplified, meaning that redundant  "is not null" check is not removed.
> In the same time, if query like 
> {code:java}
> select r_reason_desc from reason
> where r_reason_desc is not null and r_reason_desc >= 'A'{code}
> is passed to optimizer, redundant "is not null" check is eliminated.



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