[
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)
