[
https://issues.apache.org/jira/browse/CALCITE-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16734091#comment-16734091
]
Vladimir Sitnikov commented on CALCITE-2648:
--------------------------------------------
Just in case, pull/922 plans a query
{code:sql}
select x, count(*) over (order by x desc), count(*) over (order by x)
from (values (20), (35)) as t(x)
order by x desc{code}
as follows:
{noformat}
Plan after physical tweaks: EnumerableSort(sort0=[$0], dir0=[DESC]): rowcount =
2.0, cumulative cost = {6.0 rows, 33.0 cpu, 0.0 io}, id = 94
EnumerableWindow(window#0=[window(partition {} order by [0 DESC] range
between UNBOUNDED PRECEDING and CURRENT ROW aggs [COUNT()])],
window#1=[window(partition {} order by [0] range between UNBOUNDED PRECEDING
and CURRENT ROW aggs [COUNT()])]): rowcount = 2.0, cumulative cost = {4.0 rows,
9.0 cpu, 0.0 io}, id = 92
EnumerableValues(tuples=[[{ 20 }, { 35 }]]): rowcount = 2.0, cumulative
cost = {2.0 rows, 1.0 cpu, 0.0 io}, id = 78
{noformat}
In other words, it puts two windows in a single EnumerableWindow computation.
I'm inclined to have multiple LogicalWindow entities in case input's collation
satisfies window's collation.
For instance, in the 20-35 example, input's collation satisfies for {{order by
x}}, so this LogicalWindow should be put first, and {{order by x desc}} should
be computed afterwards.
> Output collation of EnumerableWindow is not consistent with its implementation
> ------------------------------------------------------------------------------
>
> Key: CALCITE-2648
> URL: https://issues.apache.org/jira/browse/CALCITE-2648
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.17.0
> Reporter: Hongze Zhang
> Assignee: Julian Hyde
> Priority: Major
>
> Here is a case:
> {code:sql}
> select x, COUNT(*) OVER (PARTITION BY x) from (values (20), (35)) as t(x)
> ORDER BY x
> {code}
> Final plan:
> {code:java}
> EnumerableWindow(window#0=[window(partition {0} order by [] range between
> UNBOUNDED PRECEDING and UNBOUNDED FOLLOWING aggs [COUNT()])])
> EnumerableValues(tuples=[[{ 20 }, { 35 }]])
> {code}
> Output rows:
> {code:java}
> X |EXPR$1 |
> ---|-------|
> 35 |1 |
> 20 |1 |
> {code}
> EnumerableWindow is supposed to preserve input collations, as a result
> EnumerableSort is ignored. However the implementation of EnumerableWindow
> generates non-ordered output (when PARTITION BY clause is used).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
