You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (JIRA)" <ji...@apache.org> on 2015/06/23 03:00:06 UTC
[jira] [Comment Edited] (CALCITE-764) Leap-frogging
[ https://issues.apache.org/jira/browse/CALCITE-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14596952#comment-14596952 ]
Julian Hyde edited comment on CALCITE-764 at 6/23/15 12:59 AM:
---------------------------------------------------------------
Attached trace.log.xz, trace log for query
{code}
!use scott
!set outputformat mysql
select sum(sal)
from "scott".emp join "scott".dept using (deptno);
!ok
{code}
compressed using xz.
was (Author: julianhyde):
trace log for query
!use scott
!set outputformat mysql
select sum(sal)
from "scott".emp join "scott".dept using (deptno);
!ok
compressed using xz.
> Leap-frogging
> -------------
>
> Key: CALCITE-764
> URL: https://issues.apache.org/jira/browse/CALCITE-764
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
> Attachments: trace.log.xz
>
>
> There is a pattern I've seen a few times where the Volcano planner creates an infinite number of very plans that are very similar but not similar enough for it to recognize that they are identical.
> Toward the end of the attached file, see the pattern
> {noformat}
> Set#442, type: RecordType(TINYINT DEPTNO)
> rel#1682:Subset#442.NONE.[], best=null, importance=0.9702989999999999
> rel#1678:LogicalAggregate.NONE.[](input=rel#1667:Subset#438.NONE.[],group={0}), rowcount=1.0, cumulative cost={inf}
> Set#443, type: RecordType(TINYINT DEPTNO, DECIMAL(7, 2) EXPR$0, TINYINT DEPTNO0)
> rel#1684:Subset#443.NONE.[], best=null, importance=0.9801
> rel#1683:LogicalJoin.NONE.[](left=rel#1681:Subset#441.NONE.[],right=rel#1682:Subset#442.NONE.[],condition==($0, $2),joinType=inner), rowcount=1.0, cumulative cost={inf}
> rel#1686:Subset#443.ENUMERABLE.[], best=null, importance=0.49005
> Set#444, type: RecordType(DECIMAL(7, 2) $f0, BIGINT $f1)
> rel#1690:Subset#444.NONE.[], best=null, importance=0.9801
> rel#1688:LogicalAggregate.NONE.[](input=rel#1684:Subset#443.NONE.[],group={},agg#0=$SUM0($1),agg#1=COUNT($1)), rowcount=1.0, cumulative cost={inf}
> Set#445, type: RecordType(TINYINT DEPTNO, DECIMAL(7, 2) EXPR$0)
> rel#1696:Subset#445.NONE.[], best=null, importance=0.9702989999999999
> rel#1692:LogicalAggregate.NONE.[](input=rel#1681:Subset#441.NONE.[],group={0},EXPR$0=SUM($1)), rowcount=1.0, cumulative cost={inf}
> Set#446, type: RecordType(TINYINT DEPTNO)
> rel#1697:Subset#446.NONE.[], best=null, importance=0.9702989999999999
> rel#1693:LogicalAggregate.NONE.[](input=rel#1682:Subset#442.NONE.[],group={0}), rowcount=1.0, cumulative cost={inf}
> Set#447, type: RecordType(TINYINT DEPTNO, DECIMAL(7, 2) EXPR$0, TINYINT DEPTNO0)
> rel#1699:Subset#447.NONE.[], best=null, importance=0.9801
> rel#1698:LogicalJoin.NONE.[](left=rel#1696:Subset#445.NONE.[],right=rel#1697:Subset#446.NONE.[],condition==($0, $2),joinType=inner), rowcount=1.0, cumulative cost={inf}
> rel#1701:Subset#447.ENUMERABLE.[], best=null, importance=0.49005
> Set#448, type: RecordType(DECIMAL(7, 2) $f0, BIGINT $f1)
> rel#1705:Subset#448.NONE.[], best=null, importance=0.9801
> rel#1703:LogicalAggregate.NONE.[](input=rel#1699:Subset#447.NONE.[],group={},agg#0=$SUM0($1),agg#1=COUNT($1)), rowcount=1.0, cumulative cost={inf}
> Set#449, type: RecordType(TINYINT DEPTNO, DECIMAL(7, 2) EXPR$0)
> rel#1711:Subset#449.NONE.[], best=null, importance=0.0
> rel#1707:LogicalAggregate.NONE.[](input=rel#1696:Subset#445.NONE.[],group={0},EXPR$0=SUM($1)), rowcount=1.0, cumulative cost={inf}
> Set#450, type: RecordType(TINYINT DEPTNO)
> rel#1712:Subset#450.NONE.[], best=null, importance=0.0
> rel#1708:LogicalAggregate.NONE.[](input=rel#1697:Subset#446.NONE.[],group={0}), rowcount=1.0, cumulative cost={inf}
> {noformat}
> and note that sets 442, 446, 450 are basically identical expressions, each based on the last.
> Does VolcanoPlanner need a new mechanism to recognize repeating structures? Or are the existing mechanisms (e.g. applying a rule and recognizing that the output is identical) sufficient?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)