--- In Firebird-Architect@yahoogroups.com,
"m_theologos" <theologos@...> wrote:

>
> Hi,
>
> Studying a little the FB indexes and some issuses about when the
> indexes are 'good' or 'bad' I have some small ideeas to put in your
> attention.
>
> 1. Siblings
>
> Perhaps you can do in the node struct a pointer to the next/prev
> sibling node (not page) ie. if we have the tree
>
> 4
> / \
> 2 6
> / \ / \
> 1 35 7
>
> Then 1 will contain Prev=nil, Next=2
> 2 will contain Prev=1, Next=3
> 3 will contain Prev=2, Next=4
> 4 will contain Prev=3, Next=5
> aso.
>
> This, IMHO, (I'm not sure, I speak from my experience with other
> environments...) will greatly enhance the tree performace in the
> cases of scan, full scan or partial, as in situations of:
>
> - Sort
> - Join
> - In optimizing the following predicates: >, <, >=, <=, Between,
> Starting with
> - Other situations which I don't know or remember, and...
>
> - ...In optimizing the CONTAINING predicate. Perhaps is necessary

to

> have a few words on this:

Also, another _big_ advantage of using siblings would be that the
indexes will be very fast navigable in _both_ ways - perhaps is
better to provide entry points to the first and the last node/page -
thus transforming it in a double-linked list (Paradox, due of this,
IIRC was at least twice as fast than Access on any indexed search) so
'oddities' like:

SELECT * FROM T ORDER BY F1; -> PLAN(IDX1)
SELECT * FROM T ORDER BY F1 DESC; -> PLAN(NATURAL)

- or -
SELECT MIN(F1) FROM T; -> PLAN(IDX1)
SELECT MAX(F1) FROM T; -> PLAN(NATURAL)

will never be seen again.

hth,

m.th.