Hi Arno,

> > > AND (NOT KAN.SUGU IS NULL)
> > > inside the last clause. Without NOT it used index(1 sec), with

NOT it didn't(6 min).

> > Hmm, interesting. Why would a NOT have this effect? I'd try a

couple

> > of changes to see if they made any impact:
>
> NOT NULL doesn't use a index, that's correct.
>

Is this also true for v1.5? I thought, that as NULL is now allowed
inside unique indexes, it doesn't matter.
There was another NOT NULL :

> > > (NOT OS.SUGU IS NULL)

and it didn't force natural on that table ..
Or is there a difference: "NOT X IS NULL" or "X IS NOT NULL"?

Anyway, after backup/restore it uses index again, so this was
probably some bad statistics combination.

> If you want to use a index think the other way :
> AND (KAN.SUGU >= <minimum value possible>) f.e. =>AND (KAN.SUGU
>= 0)
> or
> AND (KAN.SUGU >= '')
>

thanks for the tip :)

regards,
Harri