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
table.
> -------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3747
>                 URL: https://issues.apache.org/jira/browse/DERBY-3747
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL, Store
>    Affects Versions: 10.4.1.3
>            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

Mime
View raw message