Hi Set,

Unfortunately, the query is buried inside a component and is built on
the fly, so I have to wait until I am debugging that bit of code again
before I will have a better idea of what is going on. I am trying to
simplify the problem because in the real world, the query joins about
9 tables and has conditions on nearly all of them.

In any case, it is likely only to shave off 5 seconds, and there is
another part costing over a minute, so guess what gets the priority?

> > Perhaps it is as simple as an improvement to the optimiser to ignore
> > any index with a selectivity worse than ____ [insert value]. Then
> > again, perhaps this is easier said then done.
>
> You forget the case of unbalanced indexes. Suppose a cancer registry
> containing only breast cancer. An index on gender would be useless
> when looking for women, whereas it would be very good if looking for
> men (breast cancer is far more common amongst women than amongst men).

Indeed I did forget such unbalanced indices could be useful. In this
case, the index is reasonably balanced. There is one value that is
contained by about 40%, the other 60% is roughly even split.

Adam