"Dmitry Yemanov" ...
>
> "Horsun Vlad" wrote:
> >
> > А что в ASA делает препаре ? Выделяет буфер в N MB на всякий случай ? :)))
>
> К слову, оптимизировать перед выполнением вполне реально. Достаточно
> перенести код post_rse() из pass2() в exeсutor. Тогда на долю препаре
> останется парсинг, query rewrite и выделение impure. Вот только все это по
> времени блекнет на фоне оптимизации, так что практическая выгода весьма
> сомнительна. Если и думать в эту сторону, то надо продолжать оптимизировать
> в препаре, но заодно оценивать эффективность переоптимизации с учетом
> параметров. Сильно неравномерное распределение ключа может быть одним из
> таких факторов. И при достаточно положительной оценке повторять оптимизацию
> перед выполнением. Но для этого надо иметь неплохую уверенность, что план с
> учетом значений параметров будет выполнен быстрее как минимум на время
> оптимизации.
Если бы вариантов было всего 2 (индекс скан\натурал), то да, можно
было бы оставить на момен выполнения. Но это - утопия, имхо. Ведь отказ
от индексного скана в пользу натурала для одной из таблиц в джойне может
(и обычно должно) перевернуть весь порядок джойнов с ног нах.. на голову ;)
> В идеале, первая оптимизация должна устанавливать какие-то базовые точки,
> внутри которых уже будет работать повторный проход. Например, если значения
> параметров на способ джойна никак не влияют, то и нефиг заново его
> определять. Тогда накладные расходы на второй вызов будут относительно
> невелики. А то у меня перед глазами до сих пор стоит 30-секундная
> оптимизация одного запросика, делать такое дважды нафиг не надо :-)
Эк тебя проняло :)
> Но пока это все голая демагогия :-)))
Именно :)
--
Хорсун Влад
