|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
#40140364
![]() Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
Ссылка на вложение 2:
Ссылка на вложение 3:
Ссылка на вложение 4:
|
|||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
ArtToms [игнорируется] НЕВЕРОЯТНО!!!!!! на PostgreSQL ускоренный вариант ->>> на порядок быстрее!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! postgresql cross Код: SQL 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.
https://explain.tensor.ru/archive/explain/14275a45d875065152fa731c2f315dae:0:2025-03-14#explain и план какой красивый!!!------------------------------------------------------------------------- в двух словах - какая основная идея этого варианта в PostgreSQL? как получилось такое шикарное ускорение - нужно ли добавлять 'синтаксический сахар' CTE (с материализацией или без) или какой другой для красоты - нужно ли для данной структуры данных донастроить config posygresql - сейчас такой (немного памяти добавил по сравнению с коробочной настройкой) ... |
|||||||||||||||||||||||||
:
Нравится:
Не нравится:
|
|||||||||||||||||||||||||
14.03.2025, 11:29 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
#40140365
![]() Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
|
||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
... |
||||||||||||||||
:
Нравится:
Не нравится:
|
||||||||||||||||
14.03.2025, 12:06 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
Добрый день. Для меня такой результат ожидаемый, я таким способом в mssql часто пользуюсь, мне было интересно как это будет на PostgreSQL. Собственно, идея простая, заменить внешние объединения на внутренние. С внутренними проще сделать более оптимальный запрос. Это хорошо для любого sql сервера, так что и на других должно работать быстрее. В mssql аналог: cross apply. Есть еще способ перевода на внутреннее и без cross apply, но так проще и красивее. Если интересно, попробую рассказать, да и не у всех есть cross apply или такой аналог. Спасибо за подробные результаты тестов. ... |
|||
:
Изменено: 14.03.2025, 16:09 - ArtToms
Нравится:
Не нравится:
|
|||
14.03.2025, 16:07 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2025, 16:45 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] 1. переходить будем точно, еще 2 года назад планировали, последней каплей стало то что наши win клиенты с выходом win11 отрубились от базы, пришлось остаться на win10 (microsoft планомерно отключает старые tls, драйвера odbs mssql и т.д.)(к счастью мы пофиксили и то и другое - через реестр и удаление всех sql драйверов win11 и установку нужного от 2005 mssql... но ведь они обязательно еще что нибудь подкинут) 2. на счет ms express - сразу как они включили поддержку linux - поставили 12й(или 14й - не помню) - но ограничения по железу в экспрессе = низкая скорость = отказались - но используем в качестве резерва - каждую ночь туда основной бекап восстанавливаем - типа на всякий случай -------------- в итоге можно было бы успокоиться еще на пару лет но 3. политические разборки.. практически все уходят на открытые системы, и вендоры и юзеры (для меня например показатель переход ржд с oracle) -------------- к счастью руководство понимает что в конторе должен быть свой бэк/локальная база в противовес облачным монстрам Битрикс24 (которые даже бекапы не отдают)) ), а раз так и денег на серверный софт нет = дорога одна = на postgresql на llinux - к сожалению в один конец - в общем нужно остаться на волне и желательно бесплатно - поэтому только вперед)) ... |
|||
:
Изменено: 15.03.2025, 09:52 - ef1
Нравится:
Не нравится:
|
|||
15.03.2025, 09:48 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] нет предела совершенству )) пытался сократить текст запроса Код: SQL 1. 2. 3. 4. 5. 6.
Код: SQL 1.
Код: SQL 1. 2. 3. 4.
2. делал через cte нематериализованный Код: SQL 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Код: SQL 1. 2.
3. в итоге поменял внутри inner на left Код: SQL 1. 2. 3. 4. 5. 6.
единственное что не понял зачем max(vvv.value)... но без него результат короче получается по строкам короче самый красивый план и скорость при запросе в лоб!)) без извращений ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2025, 16:10 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] а вот еще интересный момент идем по двум объектам = к первому подгоняем связанный синтаксис mssql Код: SQL 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.
cross inner join Код: SQL 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.
второй - время планирования 18 мс + выполнения 13 сек план и диаграмма тоже в порядке https://explain.tensor.ru/archive/explain/787fe39e71ec68a7709aaae6b4275c92:0:2025-03-15#schema т.е когда к одному объекту подгоняем атрибуты - все ок, а к нескольким... не получается ускорится... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.03.2025, 19:02 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
Добрый день. С max, cross join lateral гарантировано возвратит одну запись, даже если результаты не найдутся (подобно left). Без него может сократиться число возвращаемых записей, похоже пробовали. В 'том то и есть изюминка. Пример, в таблице Table1 в поле id есть только положительные значения. Запрос select id from Table1 where id < 0 не вернет ни одной записи А select max(id) as id from Table1 where id < 0 вернет одну ЗАПИСЬ с пустым значением. Применять такой способ, можно если ожидаем только одну запись для каждого id. ... |
|||
:
Изменено: 15.03.2025, 19:17 - ArtToms
Нравится:
Не нравится:
|
|||
15.03.2025, 19:07 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] тему наверно закроем - каждый postgresql запрос (или его часть) нужно трассировать отдельно, хорошо у нас в базе аналитики нет ))) халява mssql кончилась)) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2025, 11:16 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
халява mssql кончилась остальное - страхи параноиков среди менеджеров, безопасников и иже с ними. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.03.2025, 12:11 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ArtToms [игнорируется] вопросик, может подскажешь вот три одинаковых выборки postgresql вариант_1 каждый атрибут читается отдельно - по твоему варианту Код: SQL 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.
много повторов >> устраните повторное выполнение одинакового кода с помощью сохранения результата или совместного вычисления значений >>сильно расходится плановая и фактическая статистика по таблице, стоит выполнить ее ANALYZE "Planning Time: 12.753 ms" "Execution Time: 15175.654 ms" https://explain.tensor.ru/archive/explain/df6925c777c7935812897d4ee62218fa:0:2025-03-23#explain по рекомендации тензора https://habr.com/ru/companies/tensor/articles/574330/ - убрал повторные чтения вариант_2 left join все атрибуты читаются кучей и разворачиваются pivot Код: SQL 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.
ни одного повтора но >>сильно расходится плановая и фактическая статистика по таблице, стоит выполнить ее ANALYZE "Planning Time: 1.804 ms" "Execution Time: 19964.939 ms" https://explain.tensor.ru/archive/explain/343bc8c6b72b3e6fba8077e240e3ff89:0:2025-03-23#explain вариант_3 cross join все атрибуты читаются кучей и разворачиваются pivot Код: SQL 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.
ни одного повтора но >>сильно расходится плановая и фактическая статистика по таблице, стоит выполнить ее ANALYZE "Planning Time: 1.906 ms" "Execution Time: 20397.222 ms" https://explain.tensor.ru/archive/explain/7a09702799792190105d94db06ddbd38:0:2025-03-23#explain вопрос - вариант 1 самый быстрый потому что планировщик ошибся на ~1000, остальные тормозят т.к. ошибка уже на ~10000 - но при этом они чище... vaсuum и analyze таблиц из выборки не помогли (https://habr.com/ru/companies/tensor/articles/479656/) типа тупик? в данном конкретном случае - варианты 2 и 3 проще и планируются на порядок быстрее но выполняются... - не хватает железа? или настройки какой то вариант 1 грязноват и план длиннее - но уже пофиг на ресурсы.... не знаю в какую сторону и смотреть ... типа главное план сделать красивым и смотреть конфиг сервера или планом не заморачиваться и в конфиг не закапываться ... ... |
|||
:
Изменено: 23.03.2025, 18:35 - ef1
Нравится:
Не нравится:
|
|||
23.03.2025, 18:26 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
mssql2005 Всем привет! готовим udf mssql базы для переезда на postgresql (санкции да и вообще все морально устарело, win11 отрубила поддержку tls1.x, 'старого' sql драйвера и т.д. - 20ти летний серверный софт 'умирает' понемногу... денег на обновление не выделяют...) вопрос по оптимизации select - одним запросом выбираем id объектов + 20 (однотипных) left join подгоняем к ним значения атрибутов mssql справляется а postgresql (на той же базе/миграция на том же запросе) 'умирает'(резко тормозит) если left join более 8~10 оставив пока postgresql в стороне просто хочу попытаться ускорить выборку на mssql например через cte (поскольку left join берет инфу из одних и тех же 4х таблиц многократно) ... структура бд от вендора (не можем менять), используем базу лет 20ть проблем нет - работает, так что вопрос чисто по ускорению запроса 1. есть 3 таблицы значений атрибутов (id атрибута, значение атрибута и т.д.) для хранения строк, чисел и дат 2. есть одна таблица связи атрибутов с объектами (id объекта, id атрибута и т.д.) в left join я просто многократно обращаюсь к этим таблицам чтобы по id объекта (из основного запроса по выборке объектов) и id атрибута получить значение атрибута вот что мы использовали последние 20 лет Код: SQL 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.
вот тоже самое через cte Код: SQL 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.
вопрос чисто эмпирический - можно ли как то ускорить запрос многократно использующий в left join одни и те-же таблицы (в данном случае) каким либо другим подходом к выборке? или это все упирается в железо сервера? ps на mssql сейчас отдельная виртуалка winserver2003+mssql2005 (здесь по скорости все более менее, количество left join глотает нормально), на postgres просто виртуалка win8.1+posgresql16 (здесь все это вообще выглядит 'мертвым' при большом количестве left join) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2025, 09:19 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] Восстановил прежний логин, ArtToms был временный. Пытаюсь понять зачем в первом запросе внутреннее соединение заменили на left join LSDBO.attrib_value? Я специально обернул внешние соединения в cross join lateral, заменив на внутренние. Так возросла скорость и "выправился" план запросов. По поводу повторов. Проанализировал исходный запрос, можно попробовать вариант с временными таблицами. Первый запрос во временную таблицу. Отбираем записи из attrib_value, с av.attrib_id перечисленными в исходном запросе. Условие where av.attrib_id in (.....), я привел для примера, лучше сделать join из значений. Код: SQL 1. 2. 3. 4.
К таблицам БД, будет всего 4 запроса, остальное с временными. Вместо временных можно попробовать cte Написал очень упрощенно, если интересно, поясню подробнее, можно пообщаться и голосом. ... |
|||
:
Изменено: 27.03.2025, 17:28 - Alex_Toms
Нравится:
Не нравится:
|
|||
27.03.2025, 17:11 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
Alex_Toms [игнорируется] честно говоря я уже запутался окончательно, но вышел на шаблон который наверно буду использовать на все про все (уже очень много времени потерял... на все это) голосом созвонится - не поможет )), бекап базы дать postgresql тоже не вариант - может не развернутся (я на 16 и 17 версии тестирую) проще удаленно подключится (в любое время в онлайне, просто время согласовать) типовой шаблон основной объект+ связанные + все их атрибуты (выборка Total rows: 39071хcols: 57 Query complete 00:01:46.296 (это без внешних функций - с ними наверно минут на 50)) - в cte набираю объекты (id и фильтрация) - в cte добавляю вызовы внешних функций - это убивает все (наверно вызовы на клиента перенесу...) - при чтении cte подгоняю к этим id значения атрибутов (и вызов результатов внешних функций...) итоговый шаблон Код: SQL 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. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2025, 11:35 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] Добрый день. это без внешних функций - с ними наверно минут на 50 Что это? Сделал вариант первого запроса, сгруппировал атрибуты, получилось три запроса к базе. Интересно попробовать на реальных данных. Время выполнения и правильно ли выводит данные? Спойлер Код: SQL 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.
... |
|||
:
Изменено: 30.03.2025, 10:22 - Alex_Toms
Нравится:
Не нравится:
|
|||
30.03.2025, 10:20 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
Alex_Toms [игнорируется] !!!круто, да чуть быстрее и план чистый (без повторов) как с pivot СПАСИБО. сейчас с этим типом запроса объектов одного типа и их атрибутами - проблем практически не осталось (ps 1. from attrib_value av inner join value_string v менял на from value_string v left join attrib_value av поскольку attrib_value очень большая ~9 000 000 строк а таблицы дат чисел и строк значительно короче.. типа гонки за микросекундами 2. >>это без внешних функций - с ними наверно минут на 50 - это в результатах итоговой select выборки - читаю вспомогательные данные из udf - подзапросы короче - в mssql теже тормоза - мои проблемы ) сейчас основная засада когда делаю запрос по нескольким объектам через left join с подгонкой атрибутов к ним в итоге в двух словах 1. если сначала собрать все id разных типов объектов в одном cte и дальше при его чтении бомбить таблицы атрибутов = более менее быстро Спойлер Код: SQL 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. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249.
имел в виду вот этот тормоз - просто общий смысл показать Спойлер Код: SQL 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. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253.
... |
|||
:
Изменено: 31.03.2025, 14:07 - ef1
Нравится:
Не нравится:
|
|||
31.03.2025, 14:04 |
|
оптимизация '+10left join' на cte (подготовка к переезду mssql>postgresql)
|
|||
---|---|---|---|
#18+
ef1 [игнорируется] Добрый день. В моем запросе после выкладке увидел опечатку, Дважды указан код 100003121500000. Убрать , max(case when av.Attrib_ID = 100003121500000 then v.value end) as ds100003121500000 и из and av.Attrib_ID in ( Мой косяк однако. Как я понял, у вас сейчас второй вариант. На вскидку, попробовать убрать внешние объединения. Получилось ведь найти более оптимальный вариант первого запроса без внешних объединений и повторов. Посмотрю на досуге, может что нибудь придумаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.03.2025, 16:35 |
|
|
start [/forum/topic.php?fid=46&gotolast=1&tid=2187185]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
448ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 565ms |
0 / 0 |