[
https://issues.apache.org/jira/browse/CALCITE-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16735186#comment-16735186
]
Vladimir Sitnikov commented on CALCITE-2648:
--------------------------------------------
{quote}I don't think LogicalWindow should have any collation. There are many
possible implementations, some of which would be sorted, others not sorted.
{quote}
Consider the following query
{code:sql}
select x.*, ROW_NUMBER() over (order by id) rn
from tab
order by id{code}
I guess adding collation to LogicalWindow is very well in line with current
Calcite code regarding collations: LogicalFilter is supposed to keep collation
even though there are many possible implementations, some of which would be
sorted others not sorted.
Even though LogicalFilter example here is a bit of a stretch, LogicalWindows
appear out of LogicalProject relations, and CalcRelSplitter should have certain
assumptions regarding the way aggregates will be computed.
I don't think we should create various permutations of LogicalWindows there (in
CalcRelSplitter) and wait for the planner to convert those to Enumerable in
order to identify the most effective ones.
I think we should apply a greedy approach and assume "sorted" implementation.
> 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)
