fast_forward vc forward

← →
Bless © (2004-09-03 11:40) [0]

Насколько я понял из book online fast_forward-курсоры соптимизированы для быстрого чтения.
Для проверки в query analizer сделал два batch-а, отличающихся только одним словом:

declare @nzs int, @nzz int
set @counter=1
declare tmp cursor
local
FAST_FORWARD (во втором - FORWARD_ONLY)
for
select nzz from pozib
set @counter=0
open tmp
fetch next from tmp into @nzz
while (@@fetch_status=0) and (@counter<=1000)
begin
fetch next from tmp into @nzz
print @nzz
set @counter=@counter+1
end
close tmp

В результате профайлер после нескольких прогонок обеих batch-ей
показал, что во ВСЕХ случаях forward_only - курсор быстрее fast_forward - курсора!

Я неправильно понял справку?
Не обеспечил чистоту эксперимента?
Или в чем тогда фишка fast_forward-а

← →
Nikolay M. © (2004-09-03 13:15) [1]

Интересно.
DEALLOCATE tmp
еще добавь. О результатах напиши.

← →
Bless © (2004-09-03 15:09) [2]

Nikolay M.[1]>

Похоже, я все-таки не обеспечил чистоту эксперимента. :)
Во-первых,
я писал тексты двух батчей в разных окнах и по очереди и в разной последовательности их запускал. На переключение между окнами уходило какое-то время, в течение которого могло что-то поменяться.
Во-вторых, я потом заметил, что на экран выводятся РАЗНЫЕ результаты, хотя тексты батчей отличаются только одним словом.
Поэтому я внес такие изменения:
1)Теперь написал оба батча в одном окне, разделив их go.
Запустил несколько раз. Потом поменял местами и еще позапускал.

2)Поменял в обоих батчах строку "select nzz from pozib"
на "select nzz from pozib order by nzz" (чтоб результаты были одинаковыми)

Результаты получились довольно близкими, причем с незначительным перевесом то в одну, то в другую сторону по параметру CPU, но с постоянным перевесом по reads (в смысле, это значение было всегда меньше) в пользу fast_forward. Поменяв в запросе @counter<=1000 на @counter<=10000 получил более убедительную картину. fast_forward все-таки быстрее оказался (где-то на 25-30 процентов).

Добавление строки DEALLOCATE tmp никак на распределение результатов вроде бы не повлияло.

← →
Ega23 © (2004-09-03 15:16) [3]

Добавление строки DEALLOCATE tmp никак на распределение результатов вроде бы не повлияло.

На результат оно и не должно было, по идее, повлиять. Это ты курсор освобождаешь таким образом. Короче, типа Free у объекта в Delphi.

> Добавление строки DEALLOCATE tmp никак на распределение
> результатов вроде бы не повлияло.

Исключительно для чистоты эксперимента. Я же на знал, при каких прочих условиях ты тестируешь.

> fast_forward все-таки быстрее оказался (где-то на 25-30
> процентов).

О чем БОЛ и говорит:

FAST_FORWARD Specifies a FORWARD_ONLY, READ_ONLY cursor with optimizations enabled. FAST_FORWARD cannot be specified if SCROLL is also specified. FAST_FORWARD and FORWARD_ONLY are mutually exclusive, if one is specified the other cannot be specified.

Nikolay M.[4]>
>Specifies a FORWARD_ONLY, READ_ONLY cursor with performance
>optimizations enabled

Тьфу ты. И чем я только смотрел? Почему-то именно эти строчки проскочили мимо моего сознания. Аж досадно, блин.

fast_forward vc forward_only Найти похожие ветки