|
|
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Поля во всех таблицах простого типа (number, varchar2(<200), date). Статистика собрана. Надо сгенерить новую таблицу на основе имеющихся данных: 1. Есть таблица порядка 80 полей и 2млн записей 2. К ней надо приаутерджойнить еще 10 таблиц в каждой порядка 100тыс записей 3. Каждая из этих 10 таблиц имеет > 15 полей, но приджойнить к большой таблиц надо только одной (то есть по одному полю джоин, другое идет в итоговый набор) 4. Джоин по намбер-полю и для каждой из 10 таблиц в исходной таблице свое поле для джоина Просто ctas из исходной "большой" таблицы выполняется за 5сек. Сделал к ней простой left outer join 10 таблиц Для каждой из 10 таблиц сделал индексы, включающие необходимые поля для запроса (по два поля в индексе, план показывает, что в джоинах читаются только индексы). Стало немного бодрее. Но: - если отключить параллельное выполнение запрос выполняется 2мин, с параллельным - 1мин (имхо долго) - план показывает что практически все джоины идут по NL + index range scan, попробовал таблицы, которые побольше переписать на use_hash, - медленно 1.5мин даже в параллели. Общий вопрос: есть ли вариант/метода эффективно саутерджойнить кучку таблиц к одной таблице? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2018, 01:48 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
ДжонАутер- если отключить параллельное выполнение запрос выполняется 2мин, с параллельным - 1мин (имхо долго)Чудак, сколько раз в час бизнесу нужно переливать все эти лямы из пустого в порожнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2018, 07:41 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Elic , речь о небольшом куске данных, на которых отлаживаюсь. Реально данных сотня млн записей и запрос отрабатвает час, что довольно долго на фоне остальных подобных запросов со сопоставимым объемом. Что из пустого в порожнее, это однозначно, но с'est la vie ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2018, 08:41 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
ДжонАутерприджойнить к большой таблиц надо только одной (то есть по одному полю джоин, другое идет в итоговый набор)ДжонАутерОбщий вопрос: есть ли вариант/метода эффективно саутерджойнить кучку таблиц к одной таблице?Попробуй скаляры. Но чтобы прочитать всё, нужно прочитать всё. И hash тут не помощник. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2018, 09:39 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
ElicПопробуй скаляры Cудя по плану, в параллели практически это и делается (NL + index range scan), но попробую, спасибо ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2018, 10:18 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
ElicНо чтобы прочитать всё, нужно прочитать всё. И hash тут не помощник Просто предполагаю, что сджойнить 2млн + 100тыс быстрее через IFFS + hash join buffered, но при параллельном запросе выбирается почему-то NL + index range scan. Но на самых простых тестовых данных выбирается-то именно IFFS + hash join, а тут что-то никак: если выключаешь параллель, то просто index fullscan (не iffs) + hash join, но работает медленнее чем NL IRS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2018, 10:33 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
ДжонАутерElicНо чтобы прочитать всё, нужно прочитать всё. И hash тут не помощник Просто предполагаю, что сджойнить 2млн + 100тыс быстрее через IFFS + hash join buffered, но при параллельном запросе выбирается почему-то NL + index range scan. Но на самых простых тестовых данных выбирается-то именно IFFS + hash join, а тут что-то никак: если выключаешь параллель, то просто index fullscan (не iffs) + hash join, но работает медленнее чем NL IRS.ресурсов ему хватает для IFFS + hash join на больших объемах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2018, 10:39 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
andreymx, на упрощенном тестовом примере из двух таблиц сопоставимого объёма выбирается именно iffs + hash join ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2018, 11:26 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
ДжонАутерandreymx, на упрощенном тестовом примере из двух таблиц сопоставимого объёма выбирается именно iffs + hash joinИ кто ведёт? Справочник? - Так это несопоставимый пример. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2018, 08:07 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Почему справочник, ведет большая таблица: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. По объему сопоставимо, по смыслу (примерно) то же. При этом IFSS выбирается и когда включено параллельное выполнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.01.2018, 12:17 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Дело оказалось вот в чем. Таблицы которые джойнятся патиционированы по списку. Джойнил я одну патицию: Код: plsql 1. Где part - ключ секции. Надеясь на то, что он возьмет эту секцию и в ней будет IFFS по локальному индексу этой же секции, но не срабатывало выбирался NL + RS Если же указать секцию явно Код: plsql 1. То IFFS подхватывается нормально. А если в локальный индекс добавить кроме нужных полей и ключ секции, то и с первым вариантом Код: plsql 1. как и ожидаешь, тоже выбирается IFFS + HASH JOIN. В общем все решилось, наверняка это есть где-нибудь в документации, но не ищем легких путей ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2018, 07:49 |
|
||
|
|

start [/forum/topic.php?fid=52&gotonew=1&tid=1884573]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
57ms |
get topic data: |
10ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 212ms |
| total: | 361ms |

| 0 / 0 |
