[
https://issues.apache.org/jira/browse/CALCITE-7697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18103065#comment-18103065
]
Alessandro Solimando commented on CALCITE-7697:
-----------------------------------------------
Thanks Julian for your input, that's a fair point. I am not opposed to mention
implantation details whenever they are relevant.
Knowing that a given optimization comes in form of a rule is important as you
must register the rule to benefit. From RelBuilder, if enabled by default as I
think it will be the case here, I was wondering if it was less relevant, as the
informative part is that Calcite will do that for me, and what I can expect
from it.
I recently inspected a plan where RelBuilder dropped a redundant aggrgate for a
nontrivial case, I was surprised to realize RelBuilder could do that. So I
agree that it can be important to know how features are implemented sometimes.
I mostly wanted to raise the point to see if the title could be simplified, but
I am happy to keep It as-is if there is agreement around it.
> 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)
