|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
FB3. Давно замечал странности, но как-то выкручивался. Вот пришло время спросить. Запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Результат: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Запрос: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Результат: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Я воспринимал CTE так. Запрос под with'ом выполняется как бы независимо, основной запрос выполняется потом. Вижу, что не так. Манипуляции с запросами под with'ом и основным приводят к совершенно разным вариантам плана запроса. Второй подзапрос под with'ом ещё усложняет ситуацию. Как уловить взаимосвязь между запросами в CTE? А то получается - подставляю какие-то костыли. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 11:09 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
KreatorXXIЯ воспринимал CTE так. Запрос под with'ом выполняется как бы независимо, основной запрос выполняется потом. Вижу, что не так.Ибо не так. CTE - это то же самое, что и VIEW, только его объявление не сохраняется в схеме БД. Тело CTE\VIEW всегда подставляется в основной запрос и рассматривается как единое целое. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 11:13 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
Упс. А я рассчитывал тратить чуть менее времени на оптимизацию запросов при использовании CTE. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 17:10 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
KreatorXXI, не вижу связи ... |
|||
:
Нравится:
Не нравится:
|
|||
18.12.2018, 19:42 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
hvlad, Для оптимизации запроса надо учитывать условия, которые "проваливаются" внутрь вью и цте. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 09:25 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
hvlad, не хотелось бы напрасно дискутировать, Вам видней. Но, ИМХО, как выразился WildSery, это "проваливание" запросов убивает весь цимус СТЕ. Формально функционал поддерживается, а реализация дело десятое. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 10:30 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
KreatorXXI, По мне так это самое "проваливание" и есть в реализации данного института самое благое. Так же, кстати, как и при использовании VIEW. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 10:35 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
KreatorXXI, э... может не надо говорить о то что ты не понимаешь? Проталкивание предикатов это часть оптимизации. Если не хочешь чтобы оно происходило можно подсказать +0 например или задать порядок через left join. Или вообще сделай так чтобы соединение шло hash join, тогда твоя CTE возможно "материализуется". Кстати в твоём запросе CTE вообще не нужна. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 10:54 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
Ок, не будем напрасно объяснять, в чём Вы заблуждаетесь ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 10:56 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
Запрос специально упростил. И, ОК, я заблуждаюсь. Но, чтобы получить более-менее приемлемую работу планировщика, приходиться тратить уйму времени на "оптимизацию" запросов, а, фактически, занимаюсь манипулированием джойнами, их порядком, хинтами... Приведённый мной пример показывает, что планировщик без всякой видимой причины пускает запрос не по тому пути. И, да, рассчитывал, что механизм CTE работает по-другому. Но, оказалось, что это СТЕ даёт удобство написания и чтения запросов. Видимо, не более того. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 12:16 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
KreatorXXI, по тому пути он пускает. Ради интереса вытащи id_spr is not null наружу, ничего не изменится. KreatorXXIКак уловить взаимосвязь между запросами в CTE? Да там достаточно просто. Пока запрос внутри CTE не содержит order by, group by, агрегатных или оконных функций, ограничителей (first, skip, rows, fetch ...), то во внутренний запрос практически всегда проталкиваются предикаты. В твоём случае всё вообще можно заменить на последовательность join без CTE. C group by то же могут проталкиваться, но только по группируемым полям (не агрегатам). И это кстати помогает весьма оптимально выполнять такие запросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 13:01 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
KreatorXXI, мы же договорились, что не будем напрасно объяснять. Я свою часть договора выполняю ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 13:05 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
hvlad, KreatorXXI, про union хитрые забыл. Может ещё что-то На самом деле главная проблема оптимизатора с CTE в том, что для сложных случаев когда предикаты не проталкиваются внутрь 1. кардинальность выборки внутри CTE не оценивается 2. outer join не умеет выполняться как hash join (это вроде в 4.0 хотели сделать) Ну и отдельная проблема это наличие left join, которые если возможно должны выполняться позже inner join. KreatorXXIНо, оказалось, что это СТЕ даёт удобство написания и чтения запросов. Видимо, не более того. не только, есть запросы которые без CTE/derived table не напишешь. И это не только рекурсивные запросы ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 13:20 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
Симонов ДенисKreatorXXI, по тому пути он пускает. Ради интереса вытащи id_spr is not null наружу, ничего не изменится. мне непонятна реакция планировщика на "id_spr is not null". Этот кусок не имеет никакого смысла. Первичный ключ. Меня интересует почему без него всё плохо? Почти на 100 процентов уверен, что, если напишу ещё какую-нибудь глупость, планировщик среагирует на неё и будет всё OK. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2018, 14:52 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
KreatorXXI мне непонятна реакция планировщика на "id_spr is not null". Этот кусок не имеет никакого смысла. а ты попробуй статистику пересчитай. Ещё можно попробовать на свежем снапшоте проверить (Дмитрий недавно что-то правил в оптимизаторе). Если всё останется так же то в трекер. Ну или пока ДЕ не прояснит ситуацию. Похоже c.id_spr is not null вырубил использование индекса по id_spr что в данном случае обернулось благом. Но CTE тут скорее всего не причём. Думаю что запрос без CTE будет вести себя так же. Ну и мне удобнее такой запрос читать вот так. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Виднее что ли кто к кому присоединён. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2018, 15:24 |
|
Работа планировщика при CTE.
|
|||
---|---|---|---|
#18+
Симонов Денис Похоже c.id_spr is not null вырубил использование индекса по id_spr что в данном случае обернулось благом. Но CTE тут скорее всего не причём. Думаю что запрос без CTE будет вести себя так же. Да, конечно. Без CTE поведение такое же. Теперь понятно, что планировщик работает также раз для CTE другого механизма нет. Значит будем ждать оптимизации работы оптимизатора. На последнем снапшоте проверить по горячим следам идея хорошая. Но вот насчёт того, что это баг, я что-то сомневаюсь. Поскольку нам очень много приходится писать запросов, сложных запросов, достаточно часто сталкиваемся с необъяснимым поведением планировщика. Поэтому CTE восприняли как благо. И написание, и чтение запросов лучше. И конечно рассчитывали в том числе и на изменения в работе планировщика. Но пока увы. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2018, 17:53 |
|
|
start [/forum/topic.php?fid=40&msg=39750000&tid=1560868]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
91ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 322ms |
total: | 516ms |
0 / 0 |