You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Zoltan Haindrich (JIRA)" <ji...@apache.org> on 2019/02/26 14:51:00 UTC

[jira] [Commented] (CALCITE-2338) Make Simplification API more conservative

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

Zoltan Haindrich commented on CALCITE-2338:
-------------------------------------------

I've bumped into this again - these extra entry points lead to that during OR simplification the recursion was invoked 2 times.

I agree on to separate them into a multiple groups at some point; right now I think closing down the cases in which simplifaction could be skipped may get some performance back.
Right now for example ReduceExpressions is doing a "push-into-case" optimization which might be as well be a member in standard simplifications.

> Make Simplification API more conservative
> -----------------------------------------
>
>                 Key: CALCITE-2338
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2338
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Zoltan Haindrich
>            Assignee: Zoltan Haindrich
>            Priority: Major
>
> Currently many lower level simplification methods are visible.
> While I was porting CALCITE-2247 to a branch near 1.16 I've bumped into an issue because of the fact that by calling a specific simplify method may leave out some otherwise applicable simplifications.
> For master there is already an extra safety feature by the presence of CALCITE-2205; it seems like using less entry points may even lead to better simplifications - by changing this; a filter have been removed.
> https://github.com/kgyrtkirk/calcite/commit/2e29a659792f6bd9419dc0f97bf5a3bdd9f6f2cc



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