Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Informix Новый топик    Ответить
 Оптимизация view с OUTER в IDS 9.4UC8  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Столкнулся с следующей проблемой:
1) есть view с большим количеством OUTER соединений на одну и ту же таблицу(полтора десятка) типа
create view test(...) as
select
from t1, t2, t3
, OUTER(sprav ts)
...
, OUTER(sprav ts)
where t1.x = t2.x and t2.x = t3.x and
and t1.a1 = ts.a
and t1.a2 = ts.a
...
and t1.a10 = ts.a
and t2.a11 = ts.a
and t2.a12 = ts.a
...
and t1.a15 = ts.a
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 такая же ситуация вообще приводила к ошибке оптимизатора.

Не сталкивался ли кто с подобной проблемой?
22 май 06, 21:06    [2693333]     Ответить | Цитировать Сообщить модератору
Все форумы / Informix Ответить