> 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:

1) Change to AND KAN.SUGU IS NOT NULL
2) Change to AND (KAN.SUGU IS NOT NULL or 2=0)

I doubt any of them will help, but running out of ideas, crazy things
may shed some light on your problem.

I agree with you that too many naturals normally make a bad plan (also
depending on where in the plan the naturals show up), but you should
also take into account other things. E.g.

SELECT a.*
FROM rdb$database a
JOIN rdb$database b on b.rdb$relation_id = a.rdb$relation_id
JOIN rdb$database c on c.rdb$relation_id = b.rdb$relation_id

would execute instantly even though there would be three naturals in
the plan.

Set