|
|
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
Ситуация: Есть запрос с набором условий SELECT * FROM users WHERE category IN (x, ..., y) AND my_sp(id) = 1 AND name LIKE '%LOH:)%' ORDER BY name; есть индексы по: name category По планам для IDS 7.31 и для 9.4 видно, что оптимизатор использует индекс по name и фильтр по category IN (x, ..., y) AND my_sp(id) = 1 НО: IDS 7.31 в последовательности category IN (x, ..., y) AND my_sp(id) = 1 а IDS 9.4: в последовательности my_sp(id) = 1 AND category IN (x, ..., y) Как вы сами понимаете, в такой ситуации эффект очень сильно зависит от "тяжеловесности" ХП my_sp. Попытки применять полную скобочную запись для управления порядком применения условий фильтра никакого эффекта не возымели - план запроса остался прежним. Приёмы типа "дублирование условия category IN (x, ..., y)" для "повышения важности условия" тоже ни к чему не привели. В общем, не знает ли кто, как можно "заставить" IDS 9.4 применять в данном случае условие my_sp(id) = 1 в ПОСЛЕДНЮЮ очередь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 16:07 |
|
||
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
С update statistics игрались ? optimizer hints пробовали ? В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2006, 19:06 |
|
||
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
ВыбегаллоС update statistics игрались ? optimizer hints пробовали ? Игрались. Пробовали. Добились следующего подключили индексы по category НО IDS 7.31 Filters в последовательности name name LIKE '%LOH:)%' AND my_sp(id) = 1 а IDS 9.4: Filters в последовательности my_sp(id) = 1 AND name LIKE '%LOH:)%' Как ему объяснить, что вызов ХП my_sp(id) более "тяжеловесный", чем name LIKE '%LOH:)%' я так и не нашёл (тем более в optimizer hint) :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 19:24 |
|
||
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
Хотелось бы увидеть схемы таблиц и текст процедуры. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2006, 20:48 |
|
||
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 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. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. QUERY: ------ SELECT {+EXPLAIN} * FROM users WHERE category IN (1, 2, 3) AND name LIKE '%LOH%' AND user_permissions(id) = 1; DIRECTIVES FOLLOWED: EXPLAIN DIRECTIVES NOT FOLLOWED: Estimated Cost: 4 Estimated # of Rows Returned: 1 1) informix.users: INDEX PATH Filters: (informix.user_permissions(informix.users.id )= 1 AND informix.users.name LIKE '%LOH%' ) (1) Index Keys: category (Serial, fragments: ALL) Lower Index Filter: informix.users.category = 1 (2) Index Keys: category (Serial, fragments: ALL) Lower Index Filter: informix.users.category = 2 (3) Index Keys: category (Serial, fragments: ALL) Lower Index Filter: informix.users.category = 3 UDRs in query: -------------- UDR id : 5354 UDR name: user_permissions QUERY: ------ SELECT {+EXPLAIN} * FROM users WHERE category IN (1, 2, 3) AND user_permissions(id) = 1 AND name LIKE '%LOH%'; DIRECTIVES FOLLOWED: EXPLAIN DIRECTIVES NOT FOLLOWED: Estimated Cost: 4 Estimated # of Rows Returned: 1 1) informix.users: INDEX PATH Filters: (informix.user_permissions(informix.users.id )= 1 AND informix.users.name LIKE '%LOH%' ) (1) Index Keys: category (Serial, fragments: ALL) Lower Index Filter: informix.users.category = 1 (2) Index Keys: category (Serial, fragments: ALL) Lower Index Filter: informix.users.category = 2 (3) Index Keys: category (Serial, fragments: ALL) Lower Index Filter: informix.users.category = 3 UDRs in query: -------------- UDR id : 5354 UDR name: user_permissions QUERY: ------ SELECT {+EXPLAIN} * FROM users WHERE category IN (1, 2, 3) AND name LIKE '%LOH%'; DIRECTIVES FOLLOWED: EXPLAIN DIRECTIVES NOT FOLLOWED: Estimated Cost: 4 Estimated # of Rows Returned: 12 1) informix.users: INDEX PATH Filters: informix.users.name LIKE '%LOH%' (1) Index Keys: category (Serial, fragments: ALL) Lower Index Filter: informix.users.category = 1 (2) Index Keys: category (Serial, fragments: ALL) Lower Index Filter: informix.users.category = 2 (3) Index Keys: category (Serial, fragments: ALL) Lower Index Filter: informix.users.category = 3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2006, 14:53 |
|
||
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
Да забыл добавить, что время работы первых двух запросов около секунды, а последний - что называется "мгновенно" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2006, 14:56 |
|
||
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
http://publib.boulder.ibm.com/epubs/html/29920280.html Bug 175113, fixed in 9.40.UC8 OPTIMIZER CHOOSES SEQUENTIAL OR INDEX SCAN DEPENDING ON THE JOIN ORDER OF TABLES не исключено, что ваша проблема - из того же разряда. В таком вот аксепте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 21:55 |
|
||
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
Выбегалло http://publib.boulder.ibm.com/epubs/html/29920280.html Bug 175113, fixed in 9.40.UC8 OPTIMIZER CHOOSES SEQUENTIAL OR INDEX SCAN DEPENDING ON THE JOIN ORDER OF TABLES не исключено, что ваша проблема - из того же разряда. В таком вот аксепте Виноват - не уточнил сразу: ситуация как раз на 9.40.UC8 :( А для него я там же нашёл "Known issues": 175426 ONLINE - SQOPTIM LEFT OUTER JOIN PERFORMS SEQUENTIAL SCANS INSTEAD OF INDEX SCAN ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2006, 12:15 |
|
||
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
АнатоЛой... 175426 ONLINE - SQOPTIM LEFT OUTER JOIN PERFORMS SEQUENTIAL SCANS INSTEAD OF INDEX SCANЭто точно не то, и вообще я не думаю что это баг, возможно просто `in` слегка потяжелел по сравнению с `=`, а тяжесть функции для оптимизатора наверно равна 0. Я бы попробовал изменить AND my_sp(id) = 1 AND my_sp(id) - 1 = 0 или на AND my_sp(id) in (1) или на AND my_sp(id)/2 between 0,49999 and 0,50001 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2006, 12:56 |
|
||
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисЭто точно не то, и вообще я не думаю что это баг УПС... С \'known issues\' я ошибся веткой - я полагал, что речь идёт о не менее актуальном для меня вопросе: Оптимизация view с OUTER в IDS 9.4UC8 Журавлев Денис , возможно просто `in` слегка потяжелел по сравнению с `=`, а тяжесть функции для оптимизатора наверно равна 0. Я бы попробовал изменить AND my_sp(id) = 1 AND my_sp(id) - 1 = 0 или на AND my_sp(id) in (1) или на AND my_sp(id)/2 between 0,49999 and 0,50001 Докладываю: Код: plaintext -- не помогло - LIKE всё ещё "тяжелее" :( Код: plaintext -- не помогло - LIKE всё ещё "тяжелее" :( Код: plaintext НАРЕШТІ! ПОМОГЛО! Хотя выражение фильтра в Query Plan не может не огорчать... ПОХОЖЕ, что IDS на каждую строку, попавшую под условие Код: plaintext Проверяем. К выше упомянутому тесту добавляем: Код: plaintext Код: plaintext и проверяем доГАДку Код: plaintext В результате получаем ошибку - подтверждение факта, что ХП вызвана 2 раза :( проверяем ещё раз: Код: plaintext Ошибки нет - найдена одна строка, ХП вызвана РОВНО 2 раза... П.С.: "И с ребятами как-то нехорошо получилось..." (с) анек ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2006, 16:29 |
|
||
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
АнатоЛой... Ошибки нет - найдена одна строка, ХП вызвана РОВНО 2 раза... П.С.: "И с ребятами как-то нехорошо получилось..." (с) анекЧестно говоря я разбираюсь в этом как свинья в апельсинах и буков опять-же много, НО я слыхал что процедуры можно пометить DETERMINISTIC, иначе откудаж он узнает что вызывать надо один раз? Или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2006, 16:43 |
|
||
|
Как IDS 7.31 и 9.4 определяют порядок применения фильтров при оптимизации запроса?
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис АнатоЛой... Ошибки нет - найдена одна строка, ХП вызвана РОВНО 2 раза... П.С.: "И с ребятами как-то нехорошо получилось..." (с) анекЧестно говоря я разбираюсь в этом как свинья в апельсинах и буков опять-же много, НО я слыхал что процедуры можно пометить DETERMINISTIC, иначе откудаж он узнает что вызывать надо один раз? Или нет? Да, с буквами тоже "нехорошо получилось" :) Вкратце смысл следующий: "Если написано <expr> BETWEEN <a> AND <b>", зачем значение <expr> 2 раза вычислять?! В доке по IDS 7, IDS 9 волшебного слова "DETERMINISTIC" не нашёл. НО: google сказал "ищи VARIANT". Штука сия появилась только в 9-ке - а я пока недостаточно силён в нюансах 9-ки :(. Результаты - те же (Informix выполняет ХП 2 РАЗА), независимо от того, как создана user_permissions, с Код: plaintext 1. или с Код: plaintext 1. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2006, 20:08 |
|
||
|
|

start [/forum/topic.php?fid=44&tid=1608638]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
59ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 225ms |
| total: | 374ms |

| 0 / 0 |
