Mihai Budiu created CALCITE-6746:
------------------------------------

             Summary: Optimization rule ProjectWindowTranspose is unsound
                 Key: CALCITE-6746
                 URL: https://issues.apache.org/jira/browse/CALCITE-6746
             Project: Calcite
          Issue Type: Bug
          Components: core
    Affects Versions: 1.38.0
            Reporter: Mihai Budiu


Here is an an example plan before and after this rule:

{code}
    LogicalProject(EXPR$0=[CASE(>($3, 0), $4, null:INTEGER)], salary=[$0], 
enroll_date=[$1]), id = 630
      LogicalWindow(window#0=[window(order by [1] range between $2 PRECEDING 
and $2 FOLLOWING aggs [COUNT($0), $SUM0($0)])]), id = 628
        LogicalProject(salary=[$2], enroll_date=[$3], $2=[*(365, 
86400000:INTERVAL DAY)]), id = 626
          LogicalTableScan(table=[[schema, empsalary]]), id = 592
{code}

after:

{code}
    LogicalProject(EXPR$0=[CASE(>($2, 0), $3, null:INTEGER)], salary=[$0], 
enroll_date=[$1]), id = 645
      LogicalWindow(window#0=[window(order by [1] range between $2 PRECEDING 
and $2 FOLLOWING aggs [COUNT($0), $SUM0($0)])]), id = 643
        LogicalProject(salary=[$0], enroll_date=[$1]), id = 639
          LogicalProject(salary=[$2], enroll_date=[$3], $2=[*(365, 
86400000:INTERVAL DAY)]), id = 633
            LogicalTableScan(table=[[schema, empsalary]]), id = 592
{code}

The problem is the representation of the window bound, which refers to field 
$2. After this optimization this field no longer exists in the project that is 
an input to the Window.

I suspect that the problem is in the code ProjectWindowTransposeRule that 
maintains the beReferred bitset; it never adds the window bounds to this set.



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

Reply via email to