Hi,

> > AND (NOT KAN.SUGU IS NULL)
> > This quey took 6 minutes(plan had 2xnatural). Without "where" clause
> > it ran ~1 sec(1xnatural). I removed all clauses and started to put
> > them back one by one. Would you beleive, that it was the "NOT"
> > inside the last clause. Without NOT it used index(1 sec), with NOT
> > it didn't(6 min). As changing of the order had no impact(as always)
> > to quey plan, I was out of ideas.
>
> 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.

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 >= '')


Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Firebird open source database (based on IB-OE) with many SQL-99 features :
http://www.firebirdsql.org
http://www.firebirdsql.info
http://www.fingerbird.de/
http://www.comunidade-firebird.org/

Support list for Interbase and Firebird users :
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep :
news://80.126.130.81