> Expanding on/explaining Martijns question. It isn't all too uncommon
> that the optimizer chooses a bad plan. But in most cases, we solve
> this by hinting/restricting the optimizer through changing our SQL in
> some silly way (e.g. by adding 0 or an empty string), rather than
> explicitly writing the plan. I have supplied a specific plan in some
> circumstances (I think it was once-off queries all the time, so I
> didn't bother to check too much if I could solve the plan problem
> otherwise), but this is normally not desirable.

A query like

select ...
from wb_prg_run w inner join objectmap m on (w.objid = m.objid)
inner join ch_pos_charge p on (m.to_objid = p.objid)

uses plan join (m natural, w index, p index) under some special
conditions (that I discussed very deeply on firebird-devel mailing
list) where it would be better to use another ordering: plan join (p
natural, m index, w index).

objid is varchar field, I tried to use +'' in on clause without
success. Other possibilty is using left join, but left join has
different result than inner join.

-- Joja