Joseph,

I'm a little late in my comments...

> -----Original Message-----
> From: Joseph Alba [mailto:jalba@...]
> Sent: Sunday, July 22, 2001 3:44 PM

...

> Point #4. Regarding Ann's suggestion of having a new improved index
> version that could result to larger indexes but avoid selectivity
> problems.
>
> Maybe Interbase can take a page from Oracle and have another index
> (Ann's index) on top of the old index. To specify that we intend to
> create this type of index, we can add the keyword 'SELECTIVITY'.
>
> e.g.
>
> CREATE INDEX BILL_TYPE ON BILL(BILL_TYPE) SELECTIVITY
>
> Without SELECTIVITY at the end, then Interbase will create
> the old style
> bitmap index which is smaller in size but has problems with
> selectivity.

Personally, given the current and ever dropping cost of hard disk space
the selectivity should always be optimized -- i.e. use the new
structure. The last thing we need to be concerned about is the cost of
hard disk space -- it is speed that most developers ever care about and
certainly the key criteria by which an engine is judged.

Also, remember that IB/FB automatically creates indexes for all foreign
key columns, and it is these indexes which create most (95%+) of the
indexing/performance problems. Accordingly, I don't think that the
developers want to have to add the new "SELECTIVITY" keyword for every
foreign keys column definition to optimize the system's performance.


Sean