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.
