|
|
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
Делаю такой групповой запрос: Код: plaintext 1. 2. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Вот и непонятно - для чего на самом деле этот COUNT() нужен и как в случае чего от него избавиться? Сам я подозреваю, что это фреймворк оптимизирует свою сторону - запрашивает вместе со всей байдой COUNT() чтобы типа как заранее выделить память под возвращаемый список, но можно ли это поведение как-то изменить - не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2008, 16:41 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
тоже встретил такую штуку, но решил не думать - скуль сам умный и исправит без проблем такие моменты. Счетчик скорее всего действительно для внутренних оптимизаций, можешь покапаться рефлектором, если хочешь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.09.2008, 01:17 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
Забавная получается парочка!Один генерит левые подзапросы, а другой посылает их в сад. На основании чего сделан вывод автор, что оптимизатор догадывается от него избавиться? Отимизатор не должен курочить запросы.Интересно посмотреть на план выполнения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2008, 11:53 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
SeVa На основании чего сделан вывод автор, что оптимизатор догадывается от него избавиться? читать умеем? человек же написал - на основании плана SeVa Отимизатор не должен курочить запросы. оптимизатор на то и оптимизатор, что он должен переделать запрос так, чтобы выполнить его наиболее оптимально. Да собственно это касается любых оптимизаторов, не только sql, или как по-твоему можно оптимизировать кусок кода, не трогая его? помолиться, чтобы он выполнился побыстрее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2008, 12:52 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
SeVaЗабавная получается парочка!Один генерит левые подзапросы, а другой посылает их в сад. На основании чего сделан вывод автор, что оптимизатор догадывается от него избавиться? Отимизатор не должен курочить запросы.Интересно посмотреть на план выполнения "Избавиться" в данном контексте означало заменить корелляцию джойном. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.09.2008, 15:03 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
зы читать умеем? человек же написал - на основании плана оптимизатор на то и оптимизатор, что он должен переделать запрос так, чтобы выполнить его наиболее оптимально. Да собственно это касается любых оптимизаторов, не только sql, или как по-твоему можно оптимизировать кусок кода, не трогая его? помолиться, чтобы он выполнился побыстрее? Читать я умею, а вот относительно того, что ты умеешь читать планы выполнения, у меня большие сомнения. Оптимизатор SQL в корне отличается от других, он только пытается построить оптимальный план выполнения и подзапросы не выбрасывает.В 2005 обязательно должен быть Aggregate(посчет count для каждой категории), а затем джойн(по-другому быть и не может),но от этого легче не станет.У меня была таблица, где продуктов было > 800К и на таком запросе пользователи могли бы смело идти на перекур. С 2008 я еще не работал и поэтому просил показать план,но даже без него понятно, что LINQ в качестве ОRM рассматривать не стоит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 14:15 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
ну я план выполнения не смотрел :) Баде поверил на слово. Посмотрел сам, план действительно содержит stream aggregate, без подзапроса ессесно все сильно короче. Но у меня данных не сильно много и много не планируется по определению, поэтому я забил. Источник появления count(*) конечно был бы интересно понять, возможно расписано на linq форумах, но пока не до них. Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 15:20 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
кстати написал запрос в таком виде (я люблю больше такую форму, отличие - отдельная явная выборка внутренней коллекции): Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 15:24 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
автору каждой медали есть две стороны, в каком ещё ORM можно с такой легкостью получить результат любой выборки? Согласен,чудес не бывает.Выигрываем в одном,проигрываем в другом.Но в итоге выигрыш оказывается весь сомнительным и БД оказывается в дауне, на основании чего делается вывод, что для SQL обязательно нужен application server и кэш. LINQ засовывает count во все запросы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 15:34 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
В догонку в EF такая же полова? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 15:36 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
SeVaВ 2005 обязательно должен быть Aggregate(посчет count для каждой категории), а затем джойн(по-другому быть и не может) Так и есть. Ниже кусок плана где это видно. А неужели вы думаете что это не быстрее чем корелляция? Особенно если учесть, что MSSQL умеет строить временные индексы когда считает это нужным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 19:53 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
зыlinq оказался достаточно умным, чтобы сделать из него точно такой же запрос :) Ну это неудивительно, если учесть, что C# сначала превращает LINQ-форму в функциональную :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 19:54 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
SeVa LINQ засовывает count во все запросы? нет конечно :) только в подобный т.н. group join ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 19:59 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
Чорный Бада Ну это неудивительно, если учесть, что C# сначала превращает LINQ-форму в функциональную :-) учитывая что процесс этот не слишком тривиальный (попробуй написать свой адаптер), то можно порадоваться что он это умеет делать достаточно умно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 20:00 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
Чорный Бада Так и есть. Ниже кусок плана где это видно. А неужели вы думаете что это не быстрее чем корелляция? Особенно если учесть, что MSSQL умеет строить временные индексы когда считает это нужным. суть в том, что если убрать этот count(*), то запрос сильно упрощается. А по сути можно и без него обойтись, просто немного сложнее будет собрать вложенную коллекцию, надо будет постоянно отслеживать то что parent запись не изменилась. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 20:01 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
SeVaLINQ засовывает count во все запросы? На самом деле вообще-то с LINQ ещё можно использовать руками написанные запросы, а не те что он генеририт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.09.2008, 20:35 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
Чорный Бада SeVaLINQ засовывает count во все запросы? На самом деле вообще-то с LINQ ещё можно использовать руками написанные запросы, а не те что он генеририт. :O Да ну... или что Вы имеете в виду? типа свой транслятор блямбда выражений в скл запросы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 09:17 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
в какой-то бете был синтаксис вызова чистого SQL, в релизе я его не нашел, к счастью :) ещё можно дергать хранимые процедуры ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 10:10 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
автор Ниже кусок плана где это видно. А неужели вы думаете что это не быстрее чем корелляция? Нисколько не быстрее.Это она и есть(именно это я и ожидал увидеть),никому ненужный подсчет кол-ва. авторв какой-то бете был синтаксис вызова чистого SQL, в релизе я его не нашел, к счастью :) ещё можно дергать хранимые процедуры Вы напрасно полагаетесь на оптимизатор-это штука достаточно дубовая, работаем методом простого перебора.При кол-ве таблиц больше пяти-шести, план может быть совсем не оптимальным.В таких случаях и нужны хинты или хранимые процедуры. Еще один момент.Все запросы должны ходить в одном направлении, иначе будут мертвые блокировки.В данном заросе нужен хинт NOLOCK. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 12:40 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
buser:O Да ну... или что Вы имеете в виду? вот это ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 13:07 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
SeVa Еще один момент.Все запросы должны ходить в одном направлении, иначе будут мертвые блокировки.В данном заросе нужен хинт NOLOCK. кстати отсутствие возможности ставить хинты во многих ORM несколько удручает. Например у нас есть система на llblgen, база большую часть дня используется только на чтение, но раз в день обновляется. Так вот в момент обновления вываливается некоторое количество блокировок, которых по-идее можно было бы избежать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 14:02 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
Больше всего в ORM удручает-корявые запросы,которые они генерят ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 14:43 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
ну не писать же все руками :) это ужасный сложноподдерживаемый страх. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 16:24 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
авторну не писать же все руками :) это ужасный сложноподдерживаемый страх Hand made всегда качественней.Подобные тулзовины скрывают тонкости, а знать сиквелевые патроха никому не помешает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 17:46 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
SeVa авторну не писать же все руками :) это ужасный сложноподдерживаемый страх Hand made всегда качественней.Подобные тулзовины скрывают тонкости, а знать сиквелевые патроха никому не помешает. Зело зависит от места их (хендсов) отростания... но это уже лирика... а так да... the devil is in the details ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 17:53 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
SeVa Hand made всегда качественней.Подобные тулзовины скрывают тонкости, а знать сиквелевые патроха никому не помешает. ещё предложи к ассемблеру вернуться, знать как работает процессор всегда полезно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 18:07 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
SeVaHand made всегда качественней.Подобные тулзовины скрывают тонкости, а знать сиквелевые патроха никому не помешает. Спасибо не надо. Насмотрелись по жизни уже вашего (ну, не лично вашего а вообще) "качественного хендмейда" :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2008, 18:33 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
Все зависит от того откуда руки растут.Агитировать никого не собираюсь, но я тоже не по наслышке знаю, что такое ORM.Далеко ходить не нужно,достаточно посмотреть на данный запрос. Здесь гарантированны дедлоки и недетские тормоза ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2008, 11:54 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
че-то меня линк сегодня сильно разочаровал запрос вроде обычный Код: plaintext превращается вот в такое дерьмище Код: plaintext 1. 2. 3. 4. 5. 6. Без Take все нормально. Дальше-хуже. Я в этом запросе делаю groupjoin и вытягиваю для каждого элемента подколлекцию. Если без Take, то все пучком. С Take - жесть и подколлекция тянется отдельным запросом на каждый элемент основного списка. Если добавить Skip, то опять все тянется за раз, правда очень страшным запросом (из-за сортировки) :) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. прям песдец какой-то, раньше я за ним такого бреда не замечал. В результате с пейджингом первая страница тянется мегадолго (из-за того что он подтягивает для каждой строки коллекцию), а все остальные мегабыстро. бред %( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2008, 00:13 |
|
||
|
LINQ to SQL - непонятный кореллированный подзапрос...
|
|||
|---|---|---|---|
|
#18+
зыпревращается вот в такое дерьмище Код: plaintext 1. 2. 3. 4. 5. 6. смотрится говённо, но, с практической точки зрения ничего страшного - ИМХО, на 30 записях чем-либо убить производительность всё равно нереально. Дальше-хуже. Я в этом запросе делаю groupjoin и вытягиваю для каждого элемента подколлекцию. Если без Take, то все пучком. С Take - жесть и подколлекция тянется отдельным запросом на каждый элемент основного списка. Тут надо было бы попробовать поиграться с опцией LoadWith(...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2008, 16:17 |
|
||
|
|

start [/forum/topic.php?all=1&fid=17&tid=1352133]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
51ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
74ms |
get tp. blocked users: |
1ms |
| others: | 246ms |
| total: | 426ms |

| 0 / 0 |
