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
