|
|
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
11.2.0.4.0 EE есть куча запросов подобного рода: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. в силу некоторых особенностей БД есть идея переписать их на scalar subquery, типа так: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. а можно на PL/SQL с RESULT_CACHE, т.е.: Код: 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. пользователи в результатах запросов обычно видят строк 200 от силы, в таблице dict примерно 2 млн. строк какой вариант предпочтительнее (конечная цель на стороне приложения справочник кешировать, но это долгосрочная перспектива)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 10:29 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
Андрей Панфилов, dict - это универсальное измерение в архитектуре EAV ? Изменения в dict случаются? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 10:34 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
Андрей Панфилов Код: plsql 1. 2. 3. 4. Здесь это не обязательно.Андрей Панфиловв таблице dict примерно 2 млн. строкВообще-то, это плохой кандидат на кэширование, особенно, если аргументы равновероятны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 10:39 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
В зависимости от данных 1 запрос может выиграть у второго. scalar subquery - кэш на уровне запроса, и будет бесмысленным если у тебя fact_t.dict1_id, fact_t.dict2_id, fact_t.dict3_id разные. RESULT_CACHE - кросс запросный кэш. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 10:39 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
envdict - это универсальное измерение в архитектуре EAV ?Можно сказать и так, но в реальности все несколько сложнее :) envИзменения в dict случаются?Довольно редко, но случаются ElicВообще-то, это плохой кандидат на кэширование, особенно, если аргументы равновероятны.Из 2 млн. измерений "равновероятных" только тысяч 50-100, остальные хорошо коррелируют с данными из таблицы фактов, т.е. при определенных условиях на таблицу фактов (что всегда соблюдается) остальных измерений будет до 1000. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 10:57 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
Андрей Панфиловкакой вариант предпочтительнее относительно выше перечисленного предпочтительней: Код: plsql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 14:21 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
Fogel, Т.е. не заполнять все измерения, если есть идентификатор для одного? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 14:29 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
Fogel, Код: 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. ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 14:31 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
ElicАндрей Панфилов Код: plsql 1. 2. 3. 4. Здесь это не обязательно. С точки зрения возвращаемых данных может и не обязательно, однако с точки зрения RESULT_CACHE разница-таки есть Код: 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. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 15:11 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
Stax, env я поторопился, не coalesce - (вернулся, чтобы поправиться, а вы уже тут, как тут), а вот так Код: plsql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 17:14 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
Андрей Панфилов, А почему нельзя сделать одно обращение к dict через OR? )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 19:06 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
ОзоА почему нельзя сделать одно обращение к dict через OR? )) OR будет множить строки как в 20725999 , а значит нужно еще group by прилепить, а учитывая что в реальности запросы несколько сложнее, да еще и в представления спрятаны с активным использованием join elimination ... решил что так делать не нужно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2017, 20:58 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
ОзоАндрей Панфилов, А почему нельзя сделать одно обращение к dict через OR? )) можете на тестовом примере показать что Вы имеете в виду ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 08:43 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
ОзоАндрей Панфилов, А почему нельзя сделать одно обращение к dict через OR? )) И получить, что-то в таком вот духе? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 09:18 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
Андрей Панфиловоднако с точки зрения RESULT_CACHE разница-таки естьСогласен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 09:25 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
env, а если ид совпадают? ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 09:58 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
Stax, В таблице фактов? Исхожу из того, что fact и dimension являются указанием на схему звезда или снежинка. И идентификатор у строки факта уникален. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 10:00 |
|
||
|
что лучше scalar subquery или PL/SQL с RESULT_CACHE
|
|||
|---|---|---|---|
|
#18+
Stax, И такой "один" проход по dict размножит строки перед агрегацией пропорционально связям с этим справочником. И можно влететь на нехватку памяти/темпа на получение всех агрегатов, до получения ожидаемых первых строк фетча. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2017, 10:03 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39505459&tid=1885422]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
435ms |
get topic data: |
14ms |
get forum data: |
4ms |
get page messages: |
76ms |
get tp. blocked users: |
2ms |
| others: | 239ms |
| total: | 808ms |

| 0 / 0 |
