> > Sorry to be so dense, but I need an explanation for this.
> >
> > Isn't an index a B*-Tree, so that all you have to do when finding
> > the maximum is to descend from each parent node to the leaf node
> > that contains the largest values?
>
> Sort of, IBPhoenix has a few excellent articles on the nitty gritty
> details of Firebird that can help you.
>
> (http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert1)
>
> Storing an index in this manner makes it more dense. This is a good
> thing, because you have fewer I/O reads in using the index. It is also
> bad, because it makes it impossible to reversly traverse (is that a
> word), go up the index. Trade offs are always a part of the fun.
>
> I am willing to accept that some of the performance issues are to do
> with the inefficiencies in the interface, as well as not having the
> appropriate directions for each index (a gotcha if you like). Also,
> something I didn't even think of earlier, it is possible that the
> other systems handle caching better. Unfortunately you can't have your
> cake and eat it. Out of interest have you taken a look at Firebird 2
> (it is alpha, not production ready). There are certainly good reports
> on the performance front.

Oh, Firebird has a new index structure (on upgraded databases) that
should perform better, btw.

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com