Когда строиться план запроса в query или в queryRun

[Murlin]

В какой момент строиться план запроса, т.е. имеет ли какой либо смысл скажем для оптимизации хранить query а затем по нему просто вызывать конструктор queryRun при условии что ограничение на другие поля у меня не устанавливается, меняются только значения ограничений.
Насколько я помню query и queryRun это динамические запросы а план по ним не кэшируется? Я прав или нет?

[S.Kuskov]

Цитата:

Сообщение от Murlin

В какой момент строиться план запроса

По логике, должен строится непосредственно перед исполнением запроса., т.е. в момент первого queryRun.Next().

[mazzy]

Цитата:

Сообщение от Murlin

В какой момент строиться план запроса

строка sql-запроса отсылается на сервер в момент первого queryRun.next()

по идее в этот же момент должен строится план запроса.
но нужно учитывать эффекты кэширования планов запроса (кэширование делает SQL)
аксапта по-умолчанию посылает запросы с плейсхолдерами"sql myfield from mytable where mytable.myfield = '%1'". если sql видит, что такой запрос уже выполнялся, то может использовать уже скомпилированный ранее план запроса.

[AndyD]

Цитата:

Сообщение от mazzy

аксапта по-умолчанию посылает запросы с литералами "sql myfield from mytable where mytable.myfield = '%1'". если sql видит, что такой запрос уже выполнялся, то может использовать уже скомпилированный ранее план запроса.

Сергей, это placeholder.
Да и поведение по умолчанию может зависить от настроек

PS Упс, уже исправил

[AndyD]

Аксапта и сама может компилировать запросы (насчет Oracle не знаю, но в MS SQL точно - с использвоанием sp_cursorprepexec), а потом использовать их повторно (sp_cursorexecute).
Вот только напрямую этим нельзя управлять. Ядро сам решает, когда это делать. Единственно, что можно - это обязательно использовать плейсхолдеры для циклических запросов

[fed]

Цитата:

Сообщение от AndyD

Аксапта и сама может компилировать запросы (насчет Oracle не знаю, но в MS SQL точно - с использвоанием sp_cursorprepexec), а потом использовать их повторно (sp_cursorexecute).
Вот только напрямую этим нельзя управлять. Ядро сам решает, когда это делать. Единственно, что можно - это обязательно использовать плейсхолдеры для циклических запросов

Справедливости ради, надо заметить, что этим можно немножко управлять, меняя максимальное число открытых курсоров в конфигурации сервера. Фактически, эта цифра управляет числом скэшированных AOSом скомпилированных запросов. Правда я не уверен что AOS позволяет уменьшить это число ниже кого порога... Я не уверен что туда можно поставить,например, число в 5 курсоров...