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

Yu Xu commented on CALCITE-7697:
--------------------------------

Thanks for the suggestions! [~asolimando]  I initially thought the title could 
be simplified as well, but since this is primarily aimed at Calcite developers 
rather than users, explicitly mentioning RelBuilder here might provide greater 
clarity. Of course, suggestions for better titles are also welcome.

> Simplify window PARTITION BY and ORDER BY keys in RelBuilder
> ------------------------------------------------------------
>
>                 Key: CALCITE-7697
>                 URL: https://issues.apache.org/jira/browse/CALCITE-7697
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.42.0
>            Reporter: Yu Xu
>            Assignee: Yu Xu
>            Priority: Major
>
> When a window function's PARTITION BY clause references a key that is 
> constant, every row falls into the same partition. The partition key 
> therefore has no effect on the result but still forces the planner (and 
> downstream engines) to perform an unnecessary partitioning/shuffle operation. 
> Calcite currently has no rule to detect and remove such redundant partition 
> keys.
> A partition key can be constant in two common ways:
>   1. *Literal partition key* — the SQL directly partitions by a constant, e.g.
> {code:java}
> SELECT empno, ROW_NUMBER() OVER (PARTITION BY 1 ORDER BY sal) FROM emp {code}
>  
>   2. *Predicate-implied constant* — an upstream predicate proves the column 
> is constant, e.g.
>  
> {code:java}
>   SELECT empno, SUM(sal) OVER (PARTITION BY deptno ORDER BY sal) FROM emp 
> WHERE deptno = 10
> {code}
>  
>  
>   2. Here deptno is constant for all surviving rows, so PARTITION BY deptno 
> is redundant.
>  The second case is the more valuable one in practice: hand-written PARTITION 
> BY <literal> is rare, but "filter on an equality column, then partition by 
> that column" arises frequently through views, nested subqueries, and 
> predicate push-down.
> we maybe can add a new rule to implement it.
>  



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

Reply via email to