Столкнулся с следующей проблемой:
1) есть view с большим количеством OUTER соединений на одну и ту же таблицу(полтора десятка) типа
2) при запросе к view explain.out выдаёт
explain.out
Estimated Cost: 2147483647
Estimated # of Rows Returned: 2147483647
...
15) informix.sprav: INDEX PATH

(1) Index Keys: id_sprav (Serial, fragments: ALL)
Lower Index Filter: informix.sprav.id_sprav = informix.x1.a9
NESTED LOOP JOIN

16) informix.sprav: SEQUENTIAL SCAN


DYNAMIC HASH JOIN
Dynamic Hash Filters: informix.sprav.id_sprav = informix.x2.a11

17) informix.sprav: SEQUENTIAL SCAN

DYNAMIC HASH JOIN
Dynamic Hash Filters: informix.sprav.id_sprav = informix.x2.a12

18) informix.sprav: INDEX PATH

(1) Index Keys: id_sprav (Serial, fragments: ALL)
Lower Index Filter: informix.sprav.id_sprav = informix.x2.a13
NESTED LOOP JOIN




ОЧЕНЬ смущает, что оптимизатор в КУЧЕ повторяющихся соединений для двух из них вместо того же INDEX PATH решил использовать SEQUENTIAL SCAN...
Кстати, по-моему в 7.31 такая же ситуация вообще приводила к ошибке оптимизатора.

Не сталкивался ли кто с подобной проблемой?