> Indeed - rdb$foreign76 is based on SYS_FILIA_ID, TOWAR_ID, STAN_ID
>and the 2=0 trick worked - 3,5 times faster than concatenation!
> I've spent quite a few years on designing databases but haven't
>learned about that one. Is it a generic rule for any SQL engine or
>something characteristic for IB/FB?

This is one of the things that Interbase/Firebird is handling poorly - I
have no experience in other c/s databases, but expect them to not have this
quirk. It sounds like Arno has done a great job in improving the optimizer
so it may not be an issue for Firebird 1.5.

In a plan, all quoted indexes will be used. In your case, it decided to use
both the primary key and another index for KOMPLET_TOWAR. The primary key
when used in a plan will normally (except if the PK consists of several
fields) uniquely identify each record, so using another index as well will
generally slow down the search (and the lower selectivity this index has,
the slower it becomes).

>Does DB engine look at EACH of the condition parts (AND...OR...) and
>looks for ANY indexes (PK, FK, IX) containing ANY of the fields used
>in the given condition part?

It looks for any indexes starting with one or more fields in 'the condition
part'.

>What in fact is enforced by 'or-ing' one of the condition parts?

(<indexed field> or <something false that isn't indexed>) simply disables
Firebird from using the index. Firebird tries to use indexes as much as
possible, so using something indexed for the or part would just slow down
things even more.

Set