был написан запрос с cte




работает медленно, а выдача небольшая


сильно быстрее работает такой вариант:



можно ли как-нибудь зафорсить для первого случая, чтобы экземпляр cte посчитался и буферизировался до всего последующего?
какие-нибудь хинты материализации существуют?

поправка

выдача cte небольшая

.Евгенийdklim.kzn,

вы для начала пробуйте все-таки искать ответ самостоятельно.
https://www.sql.ru/forum/713064/est-li-v-sql-server-analog-oraklovogo-hinta-materialize


спасибо, я искал, но не работал с ораклом

SELECT TOP (2147483647) это звучит классически ))

очень интересно

во-1 ничего не помогает, в том смысле, что запрос не завершается так же за 11 секунд, как и с переменной
ни top (2147483647)
ни top (9223372036854775807)
ни top 9223372036854775807
ни top (select 100) percent
ни top (@t) с предварительным declare @t bigint и select @t=9223372036854775807

во-2 интересно влияние option (recompile)
от него запросу плохеет ровно также, как от неприменения табличной переменной
то есть тормозит даже с использованием переменной

на самом деле в плане отличие выявилось такое, что во всех тормозящих вариантах появляется предпоследняя строка Table Spool
|--Table Spool
|--Clustered Index Scan(OBJECT:(...))

таким образом, корень зла не в материализации cte, а вообще в другой жирной буферизации
но она возникает как-то случайно) в том числе и при использовании cte вместо табличной переменной

спасибо всем ответившим

касательно recompile ситуация лучше
option (NO_PERFORMANCE_SPOOL, recompile)

но это опять таки помогает только в варианте с табличной переменной
в варианте использования cte без табличной переменной - чуть лучше, но всё равно хуже, чем с табличной переменной

не буду создавать отдельную ветку, но

есть ли удобные средства редактирования сохраненного плана?
в целом xml вроде понятен, но руками править...

кроме того минус - вроде нельзя указывать в insert/delete/uplate
(может быть, получится через указать во вью, но пока не до сук...)

TaPaKdklim.kzn,

авторкасательно recompile ситуация лучше
option (NO_PERFORMANCE_SPOOL, recompile)

автор Можно ли оптимизатору предписать сделать "временную таблицу"?
действительно решение

Да непонятно

Вроде спул и пропадает, а время исполнения не радует
Планы глянул - ну вроде отличий не увидел между двукусочным и последним с опцией

Надо детальнее смотреть, но пока отложу))
Да, еще и загрузка процессоров отличается
Единым запросом она выше
Это кроме увеличения времени

Если не ошибаюсь, первый кусок выполняется сам по себе непараллельно быстрее, чем с параллелизмом
Может быть когда он в едином запросе - из-за параллельности и тормоза и загруз
Но сам по себе он менее секунды идет, параллелизм добавляет там полсекунды

Первый кусок - это cte в табличную переменную

Короче, интересно будет потом подокопаться как-нибудь)

Персонально поздравляю с новым президентом
Пущай он и прочее станет лучше прежнего