Hi Jim,

<snip stats>

>
> Pretty much what I expected. The index is fluffier, requiring more page
> reads. If
> the benchmark has to read disk pages, your scheme is slower. If it's
> running out
> of cache, it's faster. The real world doesn't run out of cache.

I have to say that most of my customers (if not all) are having the most
important part into cache. That are not databases where the memory is much
lower than that what a database is (or would be in the future), but now i'm
ofcourse only speaking of a little fb-target-area.

> I don't think it scales. The bigger the index the more you're hurt by the
> fluffier
> index. If your index goes an extra level, you lose big time. As the

index

> size
> increases relative to cache size, your cpu advantage is lost to increased
> disk i/o.

The extra-levels aren't there that much if they even are.

> CPU double in speed every 18 months. Disks double in speed every 25

years.

> Trading increased disk traffic for lower CPU utilization isn't, to my old
> foggie thinking, a win.

Ofcourse i've to agree with that, but the index-lookup seems to be a very
expensive task on larger page sizes. While i always read (and thus adopt)
that a bigger page size should give a better performance? See for example
http://community.borland.com/article/interbase/makeibscream.pdf chapter 8,
but this seems to be not true at all. For faster index-lookups it seems a
small page size is the best.


Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Firebird links :
http://www.firebirdsql.com
http://www.firebirdsql.info
http://www.fingerbird.de/
http://www.comunidade-firebird.org/


Nederlandse firebird nieuwsgroep :
news://80.126.130.81