|
|
|
Функция TREAT - накладные расходы от частого использования?
|
|||
|---|---|---|---|
|
#18+
Использую PIPELINED функцию в комбинации с PARALLEL_ENABLE для генерирования тестовых данных. На вход подаётся одна таблица со списком "шаблонов", на выходе генерируются логически связанные между собой данные для нескольких таблиц. Данные выходят в виде объектов, которые раскладываются по таблицам с помощью multitable insert. Такой INSERT выглядит примерно так (образец): Код: 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. ("боевой" insert содержит с десяток таблиц по полтора десятка полей, выглядит страшно, но генерируется автоматически) Получается очень удобно, потому что сложная иерархическая логика распределена между объектами (в конструкторе и методах) и самой PIPELINED функцией, выглядит наглядно, изменения и добавления новых элементов и связей не тащат за собой перечитывание (как но работает??) и перекапывание кода. При выполнении иерархическая структура (клиент, его тарифы, его службы, атрибуты, и т.п.) генерируются в одном потоке, на диск пишутся тоже рядом друг с другом. Работает вроде достаточно шустро. Одним словом, отказываться от такой удобной штуки очень не хочется. Но не даёт покоя куча вызовов TREAT. Перерыл документацию и форумы, но так и не нашёл, насколько такая конструкция утяжеляет запрос (если вообще утяжеляет). Может, кто-то уже с этим сталкивался? Стоит ли ломать голову поисками оптимизаций в этом месте? Заранее спасибо! Код для теста: Код: 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. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. Входные данные для insert'a Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2016, 19:39 |
|
||
|
Функция TREAT - накладные расходы от частого использования?
|
|||
|---|---|---|---|
|
#18+
rpovarovНо не даёт покоя куча вызовов TREAT.Не вникал в смысл наследования, но даже при его наличии в чем проблема сделать коллекцию интересующего типа чтоб не делать treat? А вообще, при использовании функций, возвращающих коллекции с большим числом элементов, волновать должно даже не это, а то что конструктор вызывается для каждой строки. И вот на это могут уходить заметные накладные расходы CPU. Никотин делал неплохой тест на эту тему 12044200 . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2017, 13:25 |
|
||
|
Функция TREAT - накладные расходы от частого использования?
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopв чем проблема сделать коллекцию интересующего типа чтоб не делать treat? Вся идея была в том, что из pipelined функции потоком выходят разные форматы, которые потом раскладываются по соответствующим таблицам мульти-инсертом. И без treat не достать полей записи. А конструкторы да - жрут :( Но без объектов не получается такая красивая мультиформатная заморочка... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2017, 16:06 |
|
||
|
Функция TREAT - накладные расходы от частого использования?
|
|||
|---|---|---|---|
|
#18+
Точнее, для такого мультинсерта нужны объекты. А treat - уже последствия вынужденной работы с объектами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2017, 16:09 |
|
||
|
Функция TREAT - накладные расходы от частого использования?
|
|||
|---|---|---|---|
|
#18+
rpovarov, Я так понимаю что данные в таблицах хранялся реляционно и число атрубитов каждой строки на выходе pipelined фиксировано. Ну так сделай флажок указывающий в какую таблицу записывать и НЕ используй "is of type", "treat" и наследование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2017, 19:24 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39459972&tid=1885868]: |
0ms |
get settings: |
6ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
193ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 213ms |
| total: | 493ms |

| 0 / 0 |
