"Alexander Goldun" ...
> > Т.е. переоптимизирует при каждом выполнении ? Некузяво это, имхо
>
> Ну, смотря что с чем сравнивать. За то отсутствует понятие "плохого
> индекса", можно смело делать индексы на поля типа статусов, как описано
> в начальном посте. Мною визульно накладные расходы на оптимизацию на
> большинстве задач не обнаружены.
Да где же оно отсутствует ? Оберни запрос в процедуру, выполни её
10 раз с "хорошим" значением параметра а потом с "плохим", что будет ?
> > А если с явным препаре ?
>
> Вот что есть в доке про preparing:
>
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbpgen9/00000020.htm
> Пишут, что generate an access plan if the statement involves joins or
> subqueries.
> Что за этим скрывается на самом деле - не знаю.
Я могу только предположить: если есть для чего генерить
план - генерим :) Т.е. для CREATE TABLE, например, это не нужно
> Но похоже на запросах с
> параметрами без явного prepare план строится в зависимости от значений
> параметров.
Естественно
> > Следует ещё понимать, что в ASA (да и в MSSQL) процедура -
> > это набор _отдельных_ statement'ов, каждый из которых имеет
> > свой план выполнения, а у нас - процедура есть один statement
> > с единым планом выполнения
>
> Можно подробнее эту мысль? Что значит план для процедуры, в которой
> внутри куча разных, возможно несвязанных между собой запросов?
Есть процедура, у неё единое parse tree и единая стр-ра, подаваемая
на вход executor'у - что тут непонятного ? :) Грубо говоря - объединение
планов отдельных statement'ов (в вашем понимании)
--
Хорсун Влад
