[
https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573639#action_12573639
]
Thomas Nielsen commented on DERBY-2998:
---------------------------------------
I obviously have a lot to learn when it comes to writing my explainations in
jira... :)
Your initial analysis is identical to what I've found, and explained in an
exceptional manner.
> To make a long story short, I tried various "tweaks" (or perhaps "hacks" is a
> better word) to get the virtual column ids for PRN0 to remain correct without
> > having to clone SELECT's columns. In the end I couldn't find a clean way to
> do so.
The cloning of the RCL in PRN.genProjectRestrictNode (fragment A) was the only
way out I could find, and that again resulted in the changes 2) and 3).
I really like the fact that your "proposal" doesn't need cloning the RCL
(fragment A) - makes it all a lot cleaner.
Even though your snippet 4) feels like a hack, it might be able to pull this
logic into PRN.modifyAccessPath()?
The simplified tree looks like:
SELECT() - PRN () - SELECT()
We then call into the PRNs modifyAccessPath(), that again calls into the lower
select modifyAccessPath() where we pull the WindowNodes up and modify the RCL.
Once this is done, we could check for the presence of a PRN->WindowNode as the
top of the intial PRNs childResult, and pull the modified RCL up into the
initial PRN? By doing so I imagine we may be able to eliminate any other
problems caused by potential later/additional optimizer modifications to the
querytree. I'll give it a try at least, and see what happens.
> 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-12.diff, d2998-12.stat, d2998-13.diff, d2998-13.stat, d2998-14.diff,
> d2998-14.stat, d2998-15.diff, d2998-15.stat, d2998-16.diff, d2998-16.stat,
> d2998-17.diff, d2998-17.stat, d2998-18.diff, d2998-18.stat, 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, d2998-test4.diff, d2998-test4.stat,
> d2998-test6.diff, d2998-test7.diff, d2998-test8.diff
>
>
> 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.
