--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@...> wrote:

>
> Adam wrote:
> >
> > When you have an index, Firebird will build a bitmap of the values
> > that meet the criteria by reading the index pages. When it knows the
> > page where the data of interest is located, it will then go to the
> > page and read it, then back to the index to get the next record and so
> > on.
>
> Close, but not quite. Firebird reads then index and builds a bitmap
> of the records that match the criteria specified. So there's one pass
> to read the index and a separate pass - in storage order - to return
> the data. No back and forth between index and data ... generally.

That is a much better implementation then. :)

This is possibly OT for a reply to this post, but I am interested to
know what sort of percentage of elimination of records would you say
the cost of using the index outweighs its benefit? Obviously 1-2% is a
given that the index will not help, but what about 20%? Asides from
caching, what other factors influence this?

> The exception is when the index matches the sort list. In that case,
> Firebird bounces between index and data and returns data in sorted
> order, not storage order.

I was reading about different sorting techniques in plans on Friday so
this must have been what I was thinking.

Thanks

Adam