[jira] [Comment Edited] (CALCITE-5350) SimplifyNot with a big overhead

["Julian Hyde (Jira)" <ji...@apache.org>]

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

Julian Hyde edited comment on CALCITE-5350 at 10/29/22 10:37 PM:
-----------------------------------------------------------------

Is this a question or a bug? If it's a question, ask on the dev list. If it's a bug, please be more explicit how the actual performance differs from expected. As it currently stands, it's not possible for us to fix it because you haven't stated the problem.


was (Author: julianhyde):
Is this a question or a bug? If it's a question, ask on the dev list. If it's a bug, please be more explicit how the actual performance differs from expected.

> SimplifyNot with a big overhead
> -------------------------------
>
>                 Key: CALCITE-5350
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5350
>             Project: Calcite
>          Issue Type: Improvement
>            Reporter: raymond tsui
>            Priority: Major
>         Attachments: perf.png
>
>
> I am new here, and freshman in Sql and Calcite
> i set the IN threshold to Integer.MAX_VALUE. Original Sql look like
> {code:java}
> select a,b from t1 where c=xxx and a in(...//500 element){code}
> and then relNode look like
> {code:java}
> OR(....//$a=element above * 500){code}
> i know that IN will convert to OR when the size of IN's emelents < threshold.
> then i used perf, and i found the big overhead in RexSimplify.simplifyIs() and simplifyNot() _*[see it in attachment]*_
> i have read some calcite source code but still felt confused,Could somebody explain the whole process when Calcaite meets IN ?
> or provide some releated issues for me to learn by myself.
> thx a lot ! :)
>  
>  



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