db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-3747) provide way to implement primary key table as single btree rather than separate btree/heap table.
Date Sun, 30 Sep 2012 02:42:07 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mamta A. Satoor updated DERBY-3747:

    Urgency: Normal
     Labels: derby_triage10_10  (was: )
> provide way to implement primary key table as single btree rather than separate btree/heap
> -------------------------------------------------------------------------------------------------
>                 Key: DERBY-3747
>                 URL: https://issues.apache.org/jira/browse/DERBY-3747
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL, Store
>    Affects Versions:
>            Reporter: Mike Matrigali
>            Priority: Minor
>              Labels: derby_triage10_10
> Derby currently always stores base tables in a heap table, and then all indexing is provided
by separate indexes on top of the base table.  
> This architecture fits well with tables with small keys relative to the indexed data
and for tables that want multiple indexes on top of a single table.
> But for cases where only a single index is required the overhead could be removed.  
One option would be to just go ahead and store the whole
> table in the btree and have no heap at all.  The following issues would have to be resolved:
> 1) current btree does not support keyed/unkeyed fields.  The infrastructure is there
but just not used.  This project could be worked on independently
>      and would provide benefit to existing users.  It would allow more efficient "covered"
indexes where only part of the covered columns need be
>      be indexed.  This would also solve the problem that currently there are some types
which are not comparable and thus can't be put into 
>      a btree.  
> 2) current btree limits the size of entries, there is no "overflow" concept as is supported
in base tables.  An overflowed key is going to be a serious
>      performance issue, but would seem reasonable to support overflow non-keyed fields.
> 3) current locking strategy is "data-only" locking that uses the rowid of the heap row
as the invarient key associated with a row in the database.  Some
>      substitute would have to be created - any unique id generator stored as part of
the row in the btree in place of the row location should work.  
> 4) To support another index on such a "index base table" is a problem as the rows in
the btree will move.  So secondary indexes would have to do 
>      btree searches of the index base table to find a row.  The secondary index would
have to store the key columns of the index base table in addition
>     to any key column's of the secondary index.  
> 5) changes to language to build such an index base table  and to recognize and use such
an index, including understanding that there is no base 
>      table (or maybe it is a base table and changes need to happen to access it differently
than other "base" tables).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message