[
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
