[
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.
