db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2998) Add support for ROW_NUMBER() window function
Date Wed, 06 Feb 2008 19:21:12 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566285#action_12566285
] 

A B commented on DERBY-2998:
----------------------------

Thank you for the quick replies, Thomas.

> The MaterializedResultSet does not materialize the complete lower result before
> pulling rows from it to the upper result. 

Okay, thanks for setting me straight on that.  I scanned the code in MaterializedResultSet
and confirmed what you said, i.e. that rows are fetched one at a time and stored into a temporary
conglomerate.  It is only when (if) the scan is RE-opened again later that the temporary conglomerate
is then used for subsequent scanning.

> It might be worth looking into generating all window functions belonging to a given RCL
in the
> same WindowNode and/or WindowResultSet

For what it's worth, I tend to like that approach better, as it seems (to me) to be a more
intuitive way to handle multiple window functions in the same RCL.

> Doing that is still only valid if the functions operate on the exact same window definition

Would this be a requirement or just a preference?  If you define some kind of WindowFunctionResult
that takes "source" rows and orders/groups/filters them according to its own window definition,
then would it not be possible for each instance of WindowFunctionResult to take the same "source"
row and deal with it as necessary?  I.e. the WindowResultSet would read the source row and
then pass it down to each of its WindowFunctionResult columns, letting the latter handle the
row as needed (discard it, sort it, group it, etc.).  Not sure exactly how that might work,
but it seems feasible...

> adding handling of multiple window definitions to WindowNode and/or WindowResultSet will
> probably introduce some unnecessary complexity

It would certainly require more work to get your current code to support that, but from a
high-level view, would it result in a more complex overall design/implementation?  I don't
know one way or the other, I'm just asking the question.  And "I don't know because I haven't
tried" would be a perfectly valid answer :)

> Add support for ROW_NUMBER() window function
> --------------------------------------------
>
>                 Key: DERBY-2998
>                 URL: https://issues.apache.org/jira/browse/DERBY-2998
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL
>            Reporter: Thomas Nielsen
>            Assignee: Thomas Nielsen
>            Priority: Minor
>         Attachments: d2998-10.diff, d2998-10.stat, d2998-11.diff, d2998-4.diff, d2998-4.stat,
d2998-5.diff, d2998-5.stat, d2998-6.diff, d2998-6.stat, d2998-7.diff, d2998-7.stat, d2998-8.diff,
d2998-8.stat, d2998-9-derby.log, d2998-9.diff, d2998-9.stat, d2998-doc-1.diff, d2998-doc-1.stat,
d2998-test.diff, d2998-test.stat, d2998-test2.diff, d2998-test2.stat, d2998-test3.diff, d2998-test3.stat
>
>
> As part of implementing the overall OLAP Operations features of SQL (DERBY-581), implement
the ROW_NUMBER() window function.
> More information about this feature is available at http://wiki.apache.org/db-derby/OLAPRowNumber

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message