At 11:55 AM 6/7/2003 +0200, Arno Brinkman wrote:

>Hi Jim,
>
> > >It is not possible with the current index-structure.
> > >So my idea is for unique-index-key-lengths <= 8 (or user can force to use
> > >them) to store the full key in the index. This way we can do faster
> > >inserts/deletes/searches. I've already implemented in my local tree to
>see
> > >how much (or not) performance it would bring. The speed-win on queries
> > >(ofcourse where the index is used) is about 30-50% and the index-pages
>grow
> > >by 50% !
> >
> >
> > Doesn't sound right. Let's see your raw data.
>
>What doesn't seem right ?
>What do want to see?
>
>
>Quick explanation :
>Instead of walking over all nodes (what only can in the old structure) i
>have done this (in short explantion):

I'd like to see the performance numbers that show an improvement on some
reproducible workload.

The problem I have with your analysis is that while your algorithm may be
faster
to find a given node on a page, your index keys are significantly larger
than the
existing scheme, leading to a less dense index and increased page reads. Since
a page read takes 10 to 20 milliseconds, a couple of microseconds saved
scanning
an index page doesn't really add up.

And since the system is almost always disk bound, I have a great deal of
trouble
understanding how decreasing CPU usage at the expense of additional disk
traffic
makes anything better. And I have even more trouble understanding how making
index pages less dense can increasing system throughput by 30-50%.

So I'd like to see your performance numbers.


Jim Starkey