2009/5/15 Dmitry Yemanov <dimitr@...>

> Imagine a conjunct: "where COND_A and COND_B"
> Currently, these two conditions can be evaluated as {COND_A, COND_B} or
> {COND_B, COND_A}, depending on the compiler used to build the FB binaries.
>
> Can I safely assume that currently the optimiser leaves the evaluation
> order to the compiler only if it could not figure out a cost difference
> between COND_A and COND_B?
>



>
> For example, with a where clause like (FieldA = 'A' and FieldB = 'B'), if
> FieldA has an index, FieldB has no index, and the optimiser decides to use
> the index on FieldA, then it will always evaluate FeildA before FieldB. If
> there are no indexes on either field, then it could evaluate FieldA first or
> FieldB first depending on the compiler.
>
> In FB v2.5, it's expected that the evaluation will always be in order
> {COND_A, COND_B}, i.e. in order or their appearance in the WHERE clause
> (counting from left to right).
>
> That's something interesting to know.
>
> A smart re-ordering would mean to re-arrange the predicates based on
> their estimated cost and evaluate them from the cheapest one (e.g.
> simple comparison) to the most complex one (e.g. subquery). This is
> exactly what you were referring to in the original post of this thread.
> This is not supported in FB yet, but scheduled for the future. No
> promises it will be done in v2.5 though.
>
> Thanks for the explanation, Dmitry. Looking forward to this.
>
> Huan
>
>

[Non-text portions of this message have been removed]