Re: Indexes, Extents, Performance

No, indexes are searched by using their keys, which is similar to doing a RowID search in a table. The only time that having more than one extent will be an issue in an index is when the query is doing a RANGE-SCAN on the index, for all values between a lower and upper value. In this case the values needed may be spread between multiple extents and this could cause excessive I/Os.

Lyle D. Brooks wrote:
>
> My understanding is that having a table with multiple
> extents does not adversely affect performance if you
> are accessing the table via RowId (via an index), but
> it would if you were doing a table scan.
>
> My question is Under what conditions will index
> performance suffer if the index has multiple extents?
>
> Since we don't have indexes on indexes, I assume that
> an index can only be accessed via a "table scan" (or
> maybe the term is an "index scan"), so from that I
> would deduce that index performance is tied to the
> number of extents in the index.
>
> Is this too simple an explanation? I'd love to hear
> from anyone that has experience with this, or can
> explain performance tuning on the index itself.
>
> Thanks.
>
> Lyle
>
> --
> Lyle D. Brooks
> brooks_at_cais.com
>
> PGP public key available on request.
>
> "I'm Not Unemployed, I'm a Consultant" - Dogbert's dictum
Received on Mon Feb 16 1998 - 00:00:00 CST