|
|
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
Привет Есть табличка Код: plsql 1. 2. 3. 4. И есть запросик Код: plsql 1. 2. 3. Подскажите, пожалуйста, как ускорить запрос? Например, чтобы как-то маркировать строки с максимальным значением b over partition by a.. Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 16:34 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
посмотрите на Код: plsql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 16:46 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
Relict_35, а как быть с "кучей колонок" в случае keep? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 16:50 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
так же через KEEP ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 16:54 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
--Eugene--, Код: plsql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 16:59 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
--Eugene--, "улучшить производительность WINDOW SORT" есть два способа: 1) пытаться превратить его в WINDOW BUFFER путем создания подходящего индекса. в твоем случае, вероятно по (a, b), м.б. с учетом доп полей от прочих предикатов в условии запроса. 2) заменить его на aggregation/group by запрос окажется зависимым от того, какой смысл ты вкладываешь в термин "улучшить производительность". Например, если тебя интересует в первую очередь скорость выдачи первых строк и есть "подходящий индекс" по (a, b) в наличии, то попробуй вариант. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 17:10 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
booby, допустим, есть индекс Код: plsql 1. но в Вашем запросе он всеравно не задействуется (судя по плану) Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 17:39 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
--Eugene--, этот план соответствует запросу, который показал Egoр т.е. - произошел unnest. Прибейте его. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 17:51 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
booby--Eugene--, этот план соответствует запросу, который показал Egoр т.е. - произошел unnest. Прибейте его. По дороге поправьте Max(b) на Max(t2.b) кроме того, проверьте вариант Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 18:05 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
booby, да, работает быстро (для первых строк) но почему в плане такая заоблачная стоимость? - это она для полного фетча чтоли? Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 18:24 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
--Eugene--, ну да. годится это или нет - зависит того, что на самом деле вас интересует. а для "полного фетча" без join толку не будет. просто заставьте его бежать по индексу. поскольку сейчас вы про вакуум спрашиваете, то, с некоторой вероятностью, за прокидыванием предикатов в тот join в вашем настоящем запросе, может быть придется глазками следить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 18:32 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
--Eugene-- Код: plsql 1. то есть выбираете минимум 1/10 часть таблицы? что показывает Код: plsql 1. ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 18:54 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
boobyпытаться превратить его в WINDOW BUFFER путем создания подходящего индексаВ WINDOW BUFFER оно превратится путем создания неподходяшего индекса, с подходящим индексом можно добиться WINDOW NOSORT. 2 ТС Учитывая 10 записей на группу, использование индекса может быть не особо выгодным, так что смотри в сторону keep как было сказано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 19:09 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
xtender, Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 20:30 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
--Eugene--, а размеры сегментов таблицы и индекса на (a,b) какие? Параллелить можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 21:29 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
--Eugene--, ну и clustering_factor индекса тоже покажи. впрочем, лучше все статистики покажи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 21:35 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopboobyпытаться превратить его в WINDOW BUFFER путем создания подходящего индексаВ WINDOW BUFFER оно превратится путем создания неподходяшего индекса, с подходящим индексом можно добиться WINDOW NOSORT. это вполне пожалуйста. dbms_photoshop2 ТС Учитывая 10 записей на группу, использование индекса может быть не особо выгодным, так что смотри в сторону keep как было сказано. ппц... надували бы свой хадуп тщательнЕе. глядишь, веселее получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 23:08 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2016, 23:28 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopbooby, Это случайно не твой клон 10971123 ? :) вот чем пытаться кидаться скрытыми обвинениями в хамстве, лучше расскажите: вы что, правда верите, что в реальной таблице все a рядком друг к другу и по порядку окажутся, прямо как здесь написано: Код: plsql 1. 2. 3. 4. ? Как и в то, что пара (a, b) окажется "почти уникальной"? Имхо, это не из той истории нам картинки пытаются нарисовать. (А для случая уникальной пары (a, b) так и запросы иначе пишутся. И keep там как раз вполне годным имеет право быть) Ладно, возьмем за базу 10 записей на группу. На сколько-нибудь близком к правдоподобному распределении данных, вы на какой LIO рассчитываете в среднем на возвращенную строку, предлагая "глядеть" на keep? Блоков 10 на запись? Или поболее? Креатифф - оно шибко зашибись, но очень скушен, когда представляет собой откровенную глупость. Сам-то я не берусь предложить что-либо креативнее фильтра по индексу для затравки разговора . Но даже у этого креатива не так много шансов выскочить за 4-6 блоков на возвращенную строку на предполагаемых характеристиках таблицы. А уж куда, казалось бы, креативнее. Как-то так про клонов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2016, 02:11 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
booby, Основных подхода два - WINDOW NOSORT + INDEX FULL SCAN vs SORT GROUP BY + TABLE ACCESS FULL. В любом случае целиком сканируется либо сегмент индекса либо сегмент таблицы. Сегмент индекса чуть больше, но при его сканировании можно избежать сортировки (кроме того больше вероятность что он будет в кеше). На сортировке в этом примере особо не выиграешь независимо от кол-ва b в рамках a. Так что скорее всего полное сканирование таблицы с группировкой наиболее предпочтительный варинат (можно еще добавить параллельность). При других особенностях данных могла бы быть быстрее аналитика. Особенно если есть толстое поле, которое не нужно в результате и в индексе. Если заранее известны какие-то особенности данных, например, множество значений a, то можно было бы мудрить другие варианты. Иначе все измышлизмы относительно self join (semi join) мимо кассы. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2016, 03:28 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopИначе все измышлизмы относительно self join (semi join) мимо кассы.Хотя при индексе по двум полям a, b может дать некоторый профит, да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2016, 03:32 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
Только джойн все равно должен быть по rowid. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2016, 03:41 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
--Eugene--, Ну, раз пошла такая пьянка, то оптимизация вашей задачи детально разбирается у Кайта Best performance of Top N by X . Там есть и про нахождение всех уникальных t1.а и про нахождение top N t1.b по каждому t1.a. В вашем случае top N - это top 1. Сам этим пользуюсь, т.к. совершенно незаменимая операция при анализе динамики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2016, 07:56 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, create index xt_i on xt(a,b... шурум-брум); вот-вот. такой шурум-бурум как форму борьбы с вредоносным lio встретить-то можно. но вы же советуете keep с серьезной формой лица, без оговорок и не зная какого размера покрывающий индекс потребуется в конкретном случае. вы уш как-нибудь поосторожнее с советами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2016, 09:58 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
--Eugene--, Та задача, которую вы пытаетесь решить, встречается весьма часто, и правильного решения в рамках СУБД Oracle, к сожалению, не имеет. Как правило она связана с моделями данных, имеющих временной разрез (т.н. темпоральными данными), когда описывается состояние объекта во времени (и часто встречаются уникальные/первичные ключи типа (ID, TSTAMP) или (ID, VERSION). Для таких моделей очень популярен вид запросов "дай мне состояние данных на такой-то момент" или "покажи мне последний срез данных", которые реализуются как раз через подобного рода аналитические функции. Решение это и само по себе не очень эффективно, а уж если задача усложняется, например, хронологическим секционированием таблицы, или соединением нескольких таблиц подобной структуры, то тогда уж совсем плохо. Все известные мне решения (а я копал на эту тему достаточно давно и долго, и даже как-то Тома Кайта доставал на какой-то конференции этим вопросом) достаточно кривые, но для каких-то конкретных случаев работают workaroundы, например: 1) поддерживать избыточную таблицу с последним срезом данных (b = max_b в вашем примере) 2) добавить флажок, который идентифицирует эти данные, и добавить логику, которая обновляла бы его значения при DML в триггер на вставку. По понятным причинам эти workaroundы не столько решают проблему, сколько перекладывают ее с этапа опрашивания данных в этап их сохранения или модификации. По идее, существуют темпоральные (и даже битемпоральные) СУБД в которых такие запросы должны и кодироваться легко, и выполняться влет. Oracle к их числу, к сожалению, не относится. В 12й версии был сделан некий шаг в этом направлении (см. например "temporal validity"), но это по сути только компактный синтаксис, внутри все осталось примерно то же самое поэтому с производительностью все плохо. С уважением, Николай ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2016, 20:05 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
Nikolay SavvinovВсе известные мне решения (а я копал на эту тему достаточно давно и долго, и даже как-то Тома Кайта доставал на какой-то конференции этим вопросом) достаточно кривые, но для каких-то конкретных случаев работают ... Как раз таки решение через index lookup, о котором говориться выше отлично справляется. booby был прав с подходом, но промазал с запросом, результата его запроса я не дождался (что и логично, ведь там еще присутствует ненужный group by, да и гарантии доступа по индексу нет). На данных и индексах photoshop'a : Код: 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. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. Вообщем - то 00:00:04.45 vs 00:00:02.57 vs 00:00:00.01 , Довольно очевидно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2016, 00:02 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
Николай, попробую такой комментарий на ваш пост: По части терминологии сорта "темпоральный", "битемпоральный" и "правильного решения в рамках СУБД Oracle, к сожалению, не имеет", мое скромное мнение здесь стоит так: эта опера другими словами поется. В данном конкретном случае, речь идет всего лишь об ошибке в нормализации данных, допущенной разработчиком. в задачах на получение "срезов" в любом случае возникает join. Соединение периода актуальности среза с собственно данными, относящимися к этому срезу. Там, где он реализован через самосоединение вида Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. он и выглядит нелепо и прямо является следствием допущенной ошибки проектирования. И, также, нет сомнения, что виноват в этом только Oracle. Поскольку позволяет невинному разработчику проектировать свои данные в эдаком стиле. Ясно, что хорошая система так поступать не будет, и вовремя наставит ... разработчика на истинный путь. Поскольку такие заходы встречаются чуть менее, чем повсеместно, простым пионэрством этого не объяснишь. Имхо, в 10 случаях из 10 это является следствием того, что никакого "первого" или "последнего" среза в первоначальном дизайне просто не было. Понимание и потребность в истории срезов пришла потом - по мере развития системы. И выбран конкретный вариант как наименее затратный в смысле количества штук изменений, вносимых а архитектуру системы для минимально работоспособной реализации. Так технический дефект заливается бетоном, превращаясь архитектуру, на примере которой следующие поколения пионэров обучаются истинно правоверному би-темпоральному проектированию, одновременно с усвоением знаний о том, чего не может Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2016, 00:46 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
ora601, прошу прощения. имхо ваши изыскания целиком нерелевантны обсуждаемому случаю. здесь принципиально , что на пару (a,b) может быть возвращено произвольное количество строк, а вы исходите из предположения о том, что их не более одной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2016, 01:19 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
boobyora601, прошу прощения. имхо ваши изыскания целиком нерелевантны обсуждаемому случаю. здесь принципиально , что на пару (a,b) может быть возвращено произвольное количество строк, а вы исходите из предположения о том, что их не более одной. Нужно найти для каждой группы а , b с максимальным b. "Возвращено" (куда? ), "не более одной" (строк, пар, ? ) - какой то сплошной вакуум. Приведи пример, чтобы было более понятно о чем ты пишешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2016, 02:24 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
ora601, TC спрашивал, как найти строки у которых b максимальный. Таких строк может быть вся таблица, а может быть ни одной, а в особо тяжком случае это еще и не вся таблица. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2016, 07:51 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
Nikolay SavvinovПо понятным причинам эти workaroundы не столько решают проблему, сколько перекладывают ее с этапа опрашивания данных в этап их сохранения или модификации. По идее, существуют темпоральные (и даже битемпоральные) СУБД в которых такие запросы должны и кодироваться легко, и выполняться влет. Простите Николай. Но первое утверждение так же справедливо. Либо раскладываешь так, чтоб было удобно искать и теряешь время на записи, либо теряешь время на чтении. Да для простых случаев можно использовать хранилища типа стек и т.п. Но это только в том случае если поиск идет по дате поступления, если же информация может поступать задним числом да еще и отменяться, то хоть так, хоть эдак надо тратить время. И хранение последнего варианта отдельно не такой уж и плохой вариант и тоже один из способов решения проблемы и вполне допустимый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2016, 08:05 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев, Это SCD (slowly changing dimensions) тип 4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2016, 11:47 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
xtenderЭто SCD (slowly changing dimensions) тип 4 Ну да. Забавная, кстати, классификация. Метод 4 (по сути методы 1+2), это не метод 3, но метод 6 именно 6 потому, что 1+2+3. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2016, 14:53 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
booby, Вы берете какой-то сильно оптимистический случай, когда у вас временное измерение представлено только в одной таблице. А если их несколько, а если вся схема такая? Возьмите, для конкретности, модель данных для фондового рынка. У вас есть таблица с движениями цен, таблицы, которые задают группировки объектов по каким-то более сложным структурам, вотч листы разные, портфолио конкретных трейдеров, таблицы, которые описывают самих трейдеров и т.д и т.п. И у всех этих данных есть динамическая компонента. И постоянно вам будет нужно прогонять сложные запросы с многочисленными соединениями, которые для каждой из соединяемых таблиц будут брать данные по состоянию на какой-то конкретный момент времени. Ну то есть если вы считаете какие-то риски или балансы для какого-то трейд деска на 1е сентября 2010го года, то вам нужно брать и цены на этот момент, и состояние портфолио на этот момент, и какие трейдеры куда входили на тот момент и т.д. и т.п. Вот если вам с самого начала известны требования, как вы их реализуете? Как вы все эти таблицы будете индексировать? Как секционировать, с учетом того, что достаточно быстро счет пойдет на миллиарды строк и терабайты данных? Эта задача гораздо сложнее, чем может показаться на первый взгляд. С уважением, Николай ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2016, 15:16 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
Товарищи, кто-нибудь знает, есть ли разница между Код: plaintext Код: plaintext (кроме NULLS FIRST/LAST - допустим, колонка b not null) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2016, 19:38 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
--Eugene--, Года два назад, разницы для not null не было ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 02:10 |
|
||
|
Улучшить производительность WINDOW SORT
|
|||
|---|---|---|---|
|
#18+
xtender, не сочтите за дерзость, а откуда такая информация? (что "не было") ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2016, 03:15 |
|
||
|
|

start [/forum/topic.php?all=1&fid=52&tid=1887219]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
159ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
78ms |
get tp. blocked users: |
1ms |
| others: | 204ms |
| total: | 484ms |

| 0 / 0 |
