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

Yes, that bit sounds correct, but from what I read I thought he said
that AND (NOT KAN.SUGU IS NULL) actually removed an index from the
plan (that presumably was used due to SUGU being part of the WHERE or
JOIN clause of a view definition). And it suprises me that THAT could
happen.

Set
- I support Firebird, I am a FirebirdSQL Foundation member.
- Join today at http://www.firebirdsql.org/ff/foundation