db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-884) allow and use backward scans on indexes.
Date Fri, 03 Dec 2010 13:33:11 GMT

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

Knut Anders Hatlen commented on DERBY-884:
------------------------------------------

Thanks, Mike!

I'm cautiously optimistic that we can use BTreeScan.savePositionAndReleasePage() and BTreeScan.reposition()
more or less as they are. But as you mentioned, the search parameter passed to the scan in
reposition() probably needs to be changed to POSITION_RIGHT_OF_PARTIAL_KEY_MATCH for backward
scans. Those methods also have a nice optimization that you only do a new traversal from the
root of the BTree if a row was actually moved off of the page while the latch wasn't held.

As to the complexity of multi-column keys, did you have something specific in mind? I was
hoping that its complexity would be limited to the repositioning logic and that we could reuse
existing logic for that part.

Previous key locking is maybe also a bit tricky to get right when we're scanning backwards.
We'd probably have to obtain the previous key lock at the end of scan instead of at the beginning.
I'm not sure if that would cause any problems.

> allow and use backward scans on indexes.
> ----------------------------------------
>
>                 Key: DERBY-884
>                 URL: https://issues.apache.org/jira/browse/DERBY-884
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL, Store
>    Affects Versions: 10.1.3.1
>            Reporter: Mike Matrigali
>            Priority: Minor
>
> Improve the access interface to support backward scans, currently only forward scans
are supported.
> Improve the btree implementation to support backward scans.  The structure could support
this, the work just has not been done.  With
> row level locking, concurrent tree splitting, and current assumptions
> throughout the access method that scans go top/down, left to right the
> work to do a backward scan is harder than doing a forward scan.  Also
> once the store portion is done, there would be necessary changes to:
> optimizer, execution engine, and scan interface to allow the backward
> scan.  This would be a hard first project. 
> Improve the optimizer to understand derby indexes now support backward scans.
> Improve the execution engine to use the new backward scan interfaces to execute backward
scans.

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