OPTION (FAST 4) и производительность

[kitty]

Есть запрос на форме. Запрос использует View c computed column
Computed column дико тормозил.
Сбилась с ног, играя с запросом в sql , сравнивая и анализируя execution plans ... к своему изумлению обнаружила, что причина всех проблем в OPTION (FAST 4) , что ядро аксапты добавляет к запросу на форме. По идее, он должен ускоять выборку первых 4 строк , но ,на самом деле, в моем случае так перестраивает execution plan, что полностью убивает производительность запроса - с 1-2 секунд до 9 минут

Это все лирическое отступление...

Вопрос: можно ли отключить этот хинт для конкретной формы ?

[sukhanchik]

У объекта QueryBuildDataSource (который Вы можете получить в коде от нужного датасорса на его init) есть метод firstfast, который можно проверить - если он возвращает true, то установить его в false. Если он уже установлен в false - то тогда надо идти в БД и уже там ковырять. Смущает только что у Вас OPTION FAST 4, а не OPTION FAST 1. Обычно firstfast только одну запись пытается "ускорить". Но в любом случае - OPTION FAST 1 (или firstfast) - это зло на большом объеме данных

[Player1]

А используемая View не на базе Query (AOT\Queries)? Если так, то у датасорсов Query есть свойства FirstFast и FirstOnly...

[kitty]

Спасибо, действительно, на query легко отключается ....
Но вопрос теперь в другом: если я анализирую запрос на строне sql server, то option fast оказывает большое влияние на скорость выполнения, а если отключаю на стороне аксапты - нет (я вижу в Trace parser, что запрос , действительно без хинта уходит).

Я могу это объяснить только так: аксапта не ждет пока все записи запрос выдаст, а просто вытягивает первые N , что достаточно для показа на форме(если пользователь начнет скроллировать, то подтянет следующую порцию). Поэтому, если даже запрос целиком на sql быстрее выполняется, то при option fast первые N записей медленного запроса появляются приблизительно также быстро, как без option fast. (странно, что option fast 4 на самом деле , получается, оптимизирует появление большего количества записей, чем 4)

Как тогда, вообще, оптимизировать ? Смотреть, какой запрос на top N будет быстрей на sql выполняться? что брать за N?