db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristwaa.apa...@gmail.com>
Subject Re: Store api question: how to ask for RowLocations
Date Wed, 09 Oct 2013 20:36:28 GMT
Den 09.10.13 21:07, skrev mike matrigali:
> 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.

Thanks for the information, Mike :)

What use case(s) did you think of offhand for 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.

I have very limited experience with IOTs, but from what I've seen they 
should only be used when you know they'll make a difference. As such I'm 
not sure how much it would be used if it was ever implemented in Derby, 
but it's cool to hear it was "thought of" in such a way that 
implementing it isn't unfeasible!


Regards,
-- 
Kristian


Mime
View raw message