|
Добавление объектного типа в запрос - отрубает использование функциональных индексов
|
|||
---|---|---|---|
#18+
Не могу понять, почему у меня странно работает функциональный индекс: Код: plsql 1. 2. 3.
Если делать просто запросы к таблице с данным условием - всё работает: Код: plsql 1.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Если потом к данной таблице джойнить обычные таблицы - всё тоже очень хорошо - индекс подхватывается. Стоит только добавить в запрос объектный тип - всё, как отрубает, даже хинтами не получается заставить использовать индекс. Код: plsql 1. 2. 3. 4.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Сбор статистики не помогает - даже если сделать в таблице 10 миллионов записей - и индекс такой, что под функциональный индекс попадает только сотня (т.е селективность огромная), а всё равно не хочет выбирать по индексу. Это что какое-то ограничение оракловое ? Код: plaintext 1. 2. 3. 4. 5.
-------------------------------------------------------------- Запомните, товарищи офицеры, чтобы ничего не делать, надо уметь делать все. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2020, 21:26 |
|
Добавление объектного типа в запрос - отрубает использование функциональных индексов
|
|||
---|---|---|---|
#18+
Скорее всего фиксили какой-нибудь ORA-600, добавили ограничение. Поднимай SR, пусть ослабляют ограничение взад. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2020, 22:59 |
|
Добавление объектного типа в запрос - отрубает использование функциональных индексов
|
|||
---|---|---|---|
#18+
anvano, да, ограничение известное. TABLE() вообще вызывает кучу проблем. На современных версиях это нормально обходится добавлением виртуального столбца: Код: plsql 1. 2. 3. 4. 5.
Код: 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. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51.
А для вашей старой версии есть воркэраунд, но он крайне некрасивый и его не стоит использовать: получить имя этого скрытого столбца созданного для FBI и использовать его: Код: 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. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58.
Поэтому лучше просто создать еще одну инлайн вью, в которой и расположить все нужные предикаты: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2020, 23:06 |
|
Добавление объектного типа в запрос - отрубает использование функциональных индексов
|
|||
---|---|---|---|
#18+
anvano, Типичный костыль когда при добавлении чего-то перестает работать некий метод доступа - изолируй логику в non-mergeable inline view. Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2020, 23:17 |
|
Добавление объектного типа в запрос - отрубает использование функциональных индексов
|
|||
---|---|---|---|
#18+
Да, спасибо, inline view помог ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2020, 23:50 |
|
Добавление объектного типа в запрос - отрубает использование функциональных индексов
|
|||
---|---|---|---|
#18+
anvano, забыл добавить еще один старый воркэраунд для оракла <12: создать обычную вью, где одним из полей и будет этот вычислимый столбец и использовать ее с тем же хинтом no_merge - тогда нужные предикаты протолкнутся, да и использование станет намного удобнее. Естественно, эту вью использовать нужно только там, где это действительно нужно, дабы не напороться на другие проблемы с оптимизатором. В примере, я вместо создания отдельной юзервью просто использую with, т.к. это просто пример Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.04.2020, 02:54 |
|
|
start [/forum/topic.php?fid=52&fpage=48&tid=1881362]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
92ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
3ms |
others: | 355ms |
total: | 534ms |
0 / 0 |