You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Hongze Zhang (JIRA)" <ji...@apache.org> on 2019/01/04 19:39:00 UTC

[jira] [Comment Edited] (CALCITE-2648) Output collation of EnumerableWindow is not consistent with its implementation

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

Hongze Zhang edited comment on CALCITE-2648 at 1/4/19 7:38 PM:
---------------------------------------------------------------

[~vladimirsitnikov],

I didn't take a very detailed look at all the comments (sorry, I am a little busy on some other things these days), but I think I like the idea that leveraging the order inside a over (partition by x order by x), and the idea generating more than one LogicalWindow rels.

I have no objection to decline PR #897 and start from the better concept.

If any other people have no plan on implementing this I think I could try help, maybe start after some days.

I have a naive question here, If we can "have multiple LogicalWindow entities in case input's collation satisfies window's collation",  is there a possibility to make each Window rel only include the window group information, and use a Sort rel as input to handle the order by part? (maybe Window rels should no longer care about order) Something like:

Window(partition by x order by x)
  Input()
->
Window(partition by x)
  Sort(order by x)
    Input()

So that if the Input() is already sorted on x, the Sort(order by x) can be automatically removed by rules.



was (Author: zhztheplayer):
[~vladimirsitnikov],

I didn't take a very detailed look at all the comments (sorry, I am a little busy on some other things now), but I think I like the idea that leveraging the order inside a over (partition by x order by x), and the idea generating more than one LogicalWindow rels.

I have no objection to decline PR #897 and start from the better concept.
{quote}Would you like to implement "TL;DR:" above?
{quote}
If any other people have no plan on implementing this I think I could try help, maybe start after some days.

I have a naive question here, If we can "have multiple LogicalWindow entities in case input's collation satisfies window's collation",  is there a possibility to make each Window rel only include the window group information, and use a Sort rel as input to handle the order by part? (maybe Window rels should no longer care about order) Something like:

Window(partition by x order by x)
  Input()
->
Window(partition by x)
  Sort(order by x)
    Input()

So that if the Input() is already sorted on x, the Sort(order by x) can be automatically removed by rules.


> 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)