Arno Brinkman wrote:

> Yes, there are certainly cituations where the index does help. When a field contains only 2 values,
> but 1 value is in only 1% of the records.
> For example a table with a boolean field History. When the records are processed by a routine the
> HISTORY field is set to true, selecting all records which aren't processed yet by a query using an
> index on History is fast.

Good example. So low selectivity indices *are* useful when selecting on
a value (or set of values) that has a low hit count. Is that what you're
saying? In that case, would it be possible to save this info in the
index so that FB can see if the value(s) selected on have a low hit
count or not? I guess the MGA comes into play, messing things up...

Seem to me that the index vs. MGA problem keeps popping up whenever FB
performance problems are discussed. So any idea that would solve that
would be... well.. kind-of welcome? :-)

>>This is just one example of a performance pitfall with FB that could
>>probably be fixed.
>
> Pitty enough, you can't say that so simple else we would aready fixed that. Good ideas/suggestions
> are always welcome to the development team.

This is the kind of attitude I have been missing in this thread. Thank you!

Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64