/topic/362323

Курьезный случай вообще говоря, оптимизатор оракла задумывается, оптимизатор информикса мгновенно строит хороший план. Попробую разобраться с планами и потрассировать оракловый cbo.

select {+explain, avoid_execute}
real 0m0.148s


set optimization low;
select {+explain, avoid_execute}
real 0m0.136s


set optimization low;
select {+explain}
real 0m9.117s

Relic HunterHi
С уважением отношусь к ix. Так справедливости ради, то что он нашел план быстрее не означает, что запрос исполнился быстрее на "серьезных" данных. Я об соотношении parsing/execution/fetching. Как гооворится, лучше день потерять, зато потом за час долететь :)проблемы информикса лежат несколько в перпендикулярной плоскости.

Например в оракле мне притаскивают запрос (обычно запрос несколько сложнее таблиц так на 20 и с пятью коррелированными exists, (встречу проектировщика -- убью тупым топором)):

select *
from a,b
where a.f0=7 and a.f1=b.f1 and func1(a.f3)=0
Возвращает 100 строк
Работает 10 мин, комментирую последний предикат - 0 сек. Т.е. порядок применения предикатов, функцию надо применить в конце, постджойн. Я делаю очень просто:
select * from
(select *
from a,b
where a.f0=7 and a.f1=b.f1
and rownum>0 -- не даем оптимизатору возможности сделать merge, и push_predicate)
where func1(a.f3)=0

В информиксе пришлось бы писать через временные таблицы, и в итоге бы исполнялось 1 сек. Т.е. в информиксе просто нет понятий view merge, predicate pushing, predicate pruning (хотя может оно и есть где-то внутрях).

Поигрался с ораклом 10.2.0.1.0, план строится за 18 сек, исполняется 0.1 сек.
В плане проходы по индексу, правда ffs.
Трассировка показала что рассматривает 1348 permutations (_optimizer_max_permutations = 2000), видимо из-за дикого числа предикатов, каждая рассматривается немеряное кол-во времени, причем рассматриваются такие join methods и access methods, которых в информиксе просто не существует, плюс стоимость анализируется по двум показателям io и cpu, а не по одному.
Убирание индексов и или сбор статистики только ухудшают положение.

Relic HunterВопрос и информиксам. Как у вас обстоят дела с возвращением результирующего набора из процедуры, это возможно?
У MSSQL есть рекордсет, у Оракла реф.курсор и pipelined finctions. Что-то есть похожее тут?
Каким образом можно вернуть выборку из хранимой процедуры ? RETURN WITH RESUME

Relic HunterБлаго у Оракла есть т.н. "stored outline", т.е. можно закрепить план выполнения для запроса в системных таблицах. В таком случае повторного hardparse уже не будет :). А так-бы пришлось заганять все в хранимки.Я вам щас сикрет открою: информикс делает хардпарс в момент когда узнает значение бинд переменной препаренного курсора, т.е. каждый курсор хардпарсится, но так как время парса НИЧТОЖНО мало, это никого не парит. Лет пять назад информикс научился кешировать планы запросов, так вот этой фичей выключенной по умолчанию, никто не пользуется.

Это большой плюс и настолько же большой минус информикса.

А еще у информикса только MTS, dedicated отменили 20 лет назад.

Relic HunterКак это им удалось? У Оракла есть Shared Pool, у MSSQL такого нету, поэтому "strongly recomended" заганять даже простые селекты в хранимки, чтобы "почки" серверу не посадить :)

По сравнению sql синтаксимом оракла, синтаксис informix беден. Поэтому модель оптимизатора вероятно сильно проще, во вторых на курсах рассказывали байку что когда для 9-го информикса оптимизатор переписали с С на С++, стало сильно прозрачней и лучше, в третих нет извратов merge/sort join, iffs, т.е. у оптимизатора сильно меньше вариантов планов, в четвертых уже лет 15 всегда используются гистограммы, но самое простое объяснение что модель cbo нарисовал более сильный математик.

Relic Hunter:)
Наверное на курсах с прямым углом перепутали, informix c++ csdk.
...Речь про оптимизатор шла. Но было это давно в 01 году, может мне приснилось.