db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel DiLiberti (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3748) add support to create indexes on non key fields
Date Tue, 14 Oct 2008 17:19:44 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639496#action_12639496

Daniel DiLiberti commented on DERBY-3748:

Hello. I am looking to investigate the feasibility of attempting this improvement for a Database
Systems Implementation class. I am having issues figuring out how this would be attempted.
I  found the CreateIndexConstantAction class, which seems like it might be a good starting
point, but I don't know exactly how this class interfaces with the rest of the system and
how it is used. Any help here would be greatly appreciated, especially if there are some previous
issues relating to indices that would help me get a better grasp on the architecture of the

> add support to create indexes on non key fields
> -----------------------------------------------
>                 Key: DERBY-3748
>                 URL: https://issues.apache.org/jira/browse/DERBY-3748
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL, Store
>    Affects Versions:
>            Reporter: Mike Matrigali
>            Priority: Minor
> Add support to CREATE INDEX on non key fields.   
> Often query execution can be improved by creating indexes that include all the columns
that are returned by the query (referred to as a "covering" index).
> Currently in Derby to do this one must make all the fields part of the key, but often
the requirements of the query only need part of these columns to
> be keyed.  By making them part of the key it increases the size of the key that is used
in the non-key part of the index structure resulting in more 
> search overhead (both cpu and disk space), than is necessary.  
> The existing btree code has some framework already for non-key fields so a major rework
should not be necessary, but would not be surprised if some
> issues still remain.  Things to resolve as part of this work:
> 1) what part of sql to change, maybe just CREATE INDEX.
> 2) are there any optimizer/execution issues with the new type of index?  any metadata
changes necessary to track key vs. non-key fields?
> 3) current btree code assumes non-key fields are at end, and use non-key field stuff
for unique vs. non-unique indexes.  

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

View raw message