db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Created: (DERBY-3747) provide way to implement primary key table as single btree rather than separate btree/heap table.
Date Tue, 01 Jul 2008 17:48:45 GMT
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

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.
You can reply to this email to add a comment to the issue online.

View raw message