db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mike matrigali <mikema...@gmail.com>
Subject Re: Store api question: how to ask for RowLocations
Date Wed, 09 Oct 2013 19:07:58 GMT
On 10/9/2013 11:34 AM, Kristian Waagan wrote:
> On 02.10.13 00:20, mike matrigali wrote:
>> I don't have any good answers here, but maybe some places to look - and
>> some questions.
>>
>> Are you going to ever need RowLocations of rows in an index?  If so this
>> is going to be very new territory and Derby has never done that. For a
>> btree the RowLocation would be just the actual row as the location is
>> definined by the key - there is no other quick way given regular row
>> level locking as the row is free to move from page to page and slot to
>> slot.  The abstraction of RowLocation was designed to handle this as
>> we wanted to be able to support a btree base table if necessary, but
>> no actual implementation was ever done.
>>
>
> Hi Mike,
>
> Out of curiosity, would that btree base table be anything similar to an
> Index Organized Table (IOT) in Oracle?
> (I'm sure other products have similar, but nonetheless all to some
> degree different from each other, constructs)
>
>
> Regards,
I dont know much about oracle and had never heard this term before 
today, but based on a quick google search I would say probably yes. 
something I read says IOT is a variation on
a primary btree table but does not explain the difference.

Note current code could not support this in general.  Main work offhand 
would be storing non-key columns in btrees, allowing btree rows to be
longer than a page, need to figure out a permanent key for row locking, 
and supporting indexes pointing to other indexes.

The biggest win for such a thing is that often applications only need
a single index and making them create a base table and index is just
unnecessary overhead in both processing and storage.

Mime
View raw message