Subject | Re: Indexing tales - part 1 - Siblings |
---|---|
Author | m_theologos |
Post date | 2006-10-11T08:19:53Z |
--- In Firebird-Architect@yahoogroups.com, "Ann W.
Harrison" <aharrison@...> wrote:
didn't see any impediment, as you confirmed now. But perhaps, then,
can you do a simple lock manager in order to avoid this?
Anyway, what do you think, implementing the siblings won't do the
navigation to go faster? You know, at 65,535 items we already have a
tree with 16 levels... (...but is true that at 1,048,576 items we
have only 20 levels) which means in worst case (depending of
implementation) 16/32 comparisions and jumps to go to next node.
hth,
m. th.
Harrison" <aharrison@...> wrote:
>Thank you very much! I looked a little to the index structure I
> m_theologos wrote:
>
> >
> > Also, another _big_ advantage of using siblings would be that the
> > indexes will be very fast navigable in _both_ ways
>
> The problem with reverse navigation in Firebird indexes currently
> is not their structure, but with the necessity of avoiding internal
> deadlocks while permitting the recombination of nearly empty nodes.
> Most index problems are simple if you assume indexes are read only.
>
>
> Regards,
>
>
> Ann
>
didn't see any impediment, as you confirmed now. But perhaps, then,
can you do a simple lock manager in order to avoid this?
Anyway, what do you think, implementing the siblings won't do the
navigation to go faster? You know, at 65,535 items we already have a
tree with 16 levels... (...but is true that at 1,048,576 items we
have only 20 levels) which means in worst case (depending of
implementation) 16/32 comparisions and jumps to go to next node.
hth,
m. th.