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

[jira] [Comment Edited] (CALCITE-4578) redundant HepPlanner#buildFinalPlan when there's no rule fired in the program

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

Jiatao Tao edited comment on CALCITE-4578 at 4/12/21, 6:21 AM:
---------------------------------------------------------------

Hi [~julianhyde], thanks for your suggestion.

Yes, the best plan should be a values operator, for the simple case, it's as expected, but for my scenario, it has type coercion(has CAST), so it can not produce a VALUE(SqlToRelConverter#convertValuesImpl).
 


was (Author: aron.tao):
Hi [~julianhyde], thanks for your suggestion.

Yes, the best plan should be a values operator and I test the example SQL and it's as expected. But users can still have very large union SQL(I have met several times).

> redundant HepPlanner#buildFinalPlan when there's no rule fired in the program
> -----------------------------------------------------------------------------
>
>                 Key: CALCITE-4578
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4578
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>            Reporter: Jiatao Tao
>            Assignee: Jiatao Tao
>            Priority: Major
>         Attachments: image-2021-04-11-17-42-38-595.png
>
>
> Example like that: insert xxx VALUES (1, 'one'), (2, 'two'), (3, 'three')...(10000, 'ten thousand');
> It generates a Union node with 10000 inputs, and the performance is poor, here's the profile:
> !image-2021-04-11-17-42-38-595.png|width=1086,height=240!
> We create a program(HepProgram) to do the union merge, in this case, we only have one union, so the rule is not fired, but it will still build the buildFinalPlan, and AbstractRelNode#explain has performance issue in this case(see the flame graph):
> {code:java}
> public RelNode findBestExp() {
>   assert root != null;
>   executeProgram(mainProgram);
>   // Get rid of everything except what's in the final plan.
>   collectGarbage();
>   return buildFinalPlan(root);
> }
> {code}
> And the union has large inputs, so the performance is poor(in SetOp#replaceInput, we have to recomputeDigest ), we can skip buildFinalPlan if there's no rule fired.
>   
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)