Здравствуйте, Igorxz, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:

G>>Лучше уж такой код, чем эквивалентные простыни SQL.
I>Разумеется, это не так. (Обычно такие утвеждения делают люди, которые не работали с "серьезными" (по объему, по структуре и т.д.) БД. без обид.)
I>При работе сконкретной БД, любой, главная — это эта самая любая БД.
I>Все эти ОРМ — весчь опосредованная. По другому и быть не может.
I>В каких то ситуациях они да — берут на себя часть рутинной работы (например сгерерировать селект в целевом языке из 100 полей),
I>но главным остается все равно — движек конкретной БД.
I>(Это все следствие того, что все мало-мальски используемые движки БД на всем, что чуть сложнее прямого селекта из таблицы,
I>начинают иметь свои собственные особенности, и естеснно ни какой "волшебный" ОРМ не сможет это учесть, а главное — и не должен.
I>у него функция другая — просто сгенерировать че-то рутинное, где это можно. Что б руками это не писать.)

И что ты предлагаешь? переписать простыни linq на рукопашный SQL?
Я предлагаю посмотреть запрос, который генеируется, поправить linq, чтобы он не генерировал то, что мешает оптимизации и создать подходящие индексы.

Разница в затратах примерно на два порядка в пользу второго варианта. Возможно по итогу будет не так оптимально для конкретного варианта запроса, но в целом можно быстродействие довести до приемлемого без переписывания всего.