|
Оптимизировать запрос в котором группируется большое кол-во данных
|
|||
---|---|---|---|
#18+
Иcпользую СУБД PostgreSQL Запрос: Код: 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.
План: Код: 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.
Для некоторых аккаунтов получается большое количество записей, которые нужно сгруппировать, из-за этого запрос долго выполняется по времени и shared hit memory, у меня идей не осталось. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2021, 10:58 |
|
Оптимизировать запрос в котором группируется большое кол-во данных
|
|||
---|---|---|---|
#18+
polin11, 1)так вполне логично что чем больше записей обрабатывается тем дольше запрос. 2)обьясните смысл использования distinct в 2х местах... он там помоему ну совсем не нужен а время тратит 3)как видно запрос начинает временные файлы писать а это его сильно замедляет рекомендую поднять work_mem до уровня чтобы временных файлов не было (в вашем случае я думаю 32MB или 64MB должно хватать) 4)зачем вы 2 раза тяжелый join делаете? вам надо 1 раз сделать его а делить на user_null/user_not_null уже потом 5)зачем вы используете union там где по смыслу очевидно union all надо? откуда у вас там дубликаты в конце могут быть. 6)зачем у вас join там где exists скорее всего требуется? 7)зачем у вас фильтр по "Account" делается через with/ar вместо прямого указания pp."Account" = ANY('{3344433}'::bigint[]) ? В общем что то вида Код: 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.
Вот как то так попробуйте... и покажите план... может ещё надо будет индекс добавить. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2021, 12:41 |
|
Оптимизировать запрос в котором группируется большое кол-во данных
|
|||
---|---|---|---|
#18+
Maxim Boguk polin11, 1)так вполне логично что чем больше записей обрабатывается тем дольше запрос. 2)обьясните смысл использования distinct в 2х местах... он там помоему ну совсем не нужен а время тратит 3)как видно запрос начинает временные файлы писать а это его сильно замедляет рекомендую поднять work_mem до уровня чтобы временных файлов не было (в вашем случае я думаю 32MB или 64MB должно хватать) 4)зачем вы 2 раза тяжелый join делаете? вам надо 1 раз сделать его а делить на user_null/user_not_null уже потом 5)зачем вы используете union там где по смыслу очевидно union all надо? откуда у вас там дубликаты в конце могут быть. 6)зачем у вас join там где exists скорее всего требуется? 7)зачем у вас фильтр по "Account" делается через with/ar вместо прямого указания pp."Account" = ANY('{3344433}'::bigint[]) ? Спасибо за конструктивную помощь. 1) это понятно 2) действительно distinct лишний 3) проверил с work_mem 64MB 4) используется 2 inner join, чтобы попасть в индексы iUser и iUserNull 5) действительно нужен union all 6) проверил с exist 7) CTE таблица ar используется дальше в запросе, я привел только основную проблемную часть План запроса, который вы предложили, идет Parallel Seq Scan Код: 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.
Немного модифицировал ваш запрос, получилось чуть-лучше по времени и памяти Код: 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.
План модифицированного запроса Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2021, 12:20 |
|
Оптимизировать запрос в котором группируется большое кол-во данных
|
|||
---|---|---|---|
#18+
polin11, У вас не хватает индекса по "Documents"("Account") что я и подозревал когда писал про "и покажите план... может ещё надо будет индекс добавить." Тогда и быстрее будет. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2021, 12:37 |
|
Оптимизировать запрос в котором группируется большое кол-во данных
|
|||
---|---|---|---|
#18+
polin11, Ещё можно сделать без union all и без WITH вообще. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
-- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2021, 12:43 |
|
|
start [/forum/topic.php?fid=53&msg=40100178&tid=1993848]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
30ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 132ms |
0 / 0 |