Subject | Re: [firebird-support] Re: Performance of Firebird vs. other DBMS |
---|---|
Author | Kjell Rilbe |
Post date | 2005-08-17T13:33:58Z |
laurenz_brein wrote:
can't navigate backwards due to the unidirectional nature of the index.
Getting the N last entries at once enables you to scan backwards in that
cached set of entries, but the index might actualyl be updated by other
transactions right in the middle of doing this, so the result might be
incorrect. And for sure, if the max to be returned is not in the set you
fetch, you'll have to cache several index pages. Again, the index pages
might change between the point where you cache them and the point where
you use them. It won't work.
Note: I'm don't know a lot about FB's architecture - I'm a mere user, so
others might have to correct me. :-)
Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
> Please bear with me, I still fail to grasp it.The problem is that once it has found the last entry in the index it
> Why is it so much more expensive to get that last entry (or last
> couple of entries) from a B*-Tree than it is to get the first entry?
can't navigate backwards due to the unidirectional nature of the index.
Getting the N last entries at once enables you to scan backwards in that
cached set of entries, but the index might actualyl be updated by other
transactions right in the middle of doing this, so the result might be
incorrect. And for sure, if the max to be returned is not in the set you
fetch, you'll have to cache several index pages. Again, the index pages
might change between the point where you cache them and the point where
you use them. It won't work.
Note: I'm don't know a lot about FB's architecture - I'm a mere user, so
others might have to correct me. :-)
Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64