Форум программистов, компьютерный форум, киберфорум
PostgreSQL
Форум программистов и сисадминов Киберфорум > Форум программистов > Базы данных > PostgreSQL
Войти
Регистрация
Восстановить пароль
Блоги Сообщество Поиск  
 
2 из 2 « 1 2
 
Рейтинг 4.75/8: Рейтинг темы: голосов - 8, средняя оценка - 4.75
0 / 0 / 0
Регистрация: 01.12.2014
Сообщений: 118

Стал очень медленно работать запрос после обновления версии PostgreSQL

27.08.2024, 00:31. Показов 3342. Ответов 28
Метки нет (Все метки)
Студворк — интернет-сервис помощи студентам
Здравствуйте!

Столкнулся с такой проблемой, стал гораздо медленнее отрабатывать запрос после обновления Postgres PRO Ent 11 на Ent 15.
На старой версии выполняется примерно за 10 сек., на новой за 13 минут. Прилагаю сам текст запроса и два плана выполнения для сравнения.
Железо одинаковое, конфигурация postgresql.conf одна и та же. Что уже сделал, analyze всех таблиц, перестроение всех индексов. В конфигурации для эксперимента отключил все параметры которых не было в 11, появились в 15 и включены по умолчанию, но никакого эффекта это не дало.
Единственное что более менее помогает, это принудительно отключить seq_scan = off.

Может есть идеи, в какую сторону копать? Есть ли смысл экспериментировать с настройками планировщика?

Заранее спасибо!

Кликните здесь для просмотра всего текста
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

SELECT
r.*, COUNT(*) OVER() total_rows
FROM (SELECT rb.id, 
rb.req_number, 
rb.req_status, 
rb.id_own_customer, 
rb.id_user_create, 
rb.date_create, 
rb.contact_person, 
rb.phone_number, 
rb.id_org_user_create, 
rb.responsible, 
rb.plan_weight, 
rb.fact_weight, 
(SELECT descr_org FROM customer_organizations 
WHERE rb.id_out_customer = id) descr_out_customer, 
(SELECT name FROM organizations
WHERE rb.id_own_customer = id_org) descr_own_customer, 
qaverage.route_distance, qaverage.mileage, 
qaverage.mileage_in_route, 
qaverage.cnt_trip, qaverage.progress, 
p.reg_numbers, rc.max_plan_date_start, rc.max_plan_date_finish, 
rc.min_plan_date_start, rc.min_plan_date_finish, rc.contractors 
FROM request_ts_base rb
LEFT JOIN LATERAL(SELECT re.id_request, 
string_agg(corg.descr_org, ' ') FILTER(WHERE re.contractor IS NOT NULL) contractors, 
MAX(re.date_start) max_plan_date_start, 
MAX(re.date_finish) max_plan_date_finish, 
MIN(re.date_start) min_plan_date_start, 
MIN(re.date_finish) min_plan_date_finish 
FROM request_ts_extension re LEFT JOIN
customer_organizations corg ON corg.id = re.contractor 
WHERE re.id_request = rb.id GROUP BY re.id_request) rc 
ON TRUE LEFT JOIN LATERAL(SELECT avg(route_distance) route_distance, 
avg(mileage) mileage, avg(mileage_in_route) mileage_in_route, 
avg(cnt_trip) cnt_trip, avg(progress) progress FROM request_ts_transport 
WHERE request_ts_transport.id_request = rb.id) 
qaverage ON TRUE LEFT JOIN(SELECT string_agg(p1.reg_number, '<AE>') reg_numbers, p1.id_request 
FROM(SELECT p0.reg_number, rt0.id_request FROM passport p0 JOIN
request_ts_transport rt0 ON rt0.id_ts = p0.id_mo UNION ALL SELECT tc1.reg_number, tc1.id_request 
FROM request_transport_cont tc1 LEFT JOIN request_ts_base rtb ON rtb.id = tc1.id_request) p1
GROUP BY p1.id_request) p ON p.id_request = rb.id) r
WHERE
  r.date_create >= '2024-08-16 17:00:00' AND
  r.date_create < '2024-08-22 17:00:00' AND
  r.responsible = 100641 AND
  r.id_org_user_create IN (
SELECT
      child_org_id
    FROM
      org_access
    WHERE
      org_access.parent_org_id = 1657375583)
      ORDER BY
r.date_create DESC, r.req_number DESC, r.id DESC


План выполнения на 11 версии:
Кликните здесь для просмотра всего текста
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

Sort  (cost=1714930.22..1714930.67 ROWS=178 width=992) (actual TIME=15279.127..15279.129 ROWS=45 loops=1)
   Sort KEY: rb.date_create DESC, rb.req_number DESC, rb.id DESC
   Sort Method: quicksort  Memory: 65kB
   Buffers: shared hit=1378008, temp READ=19958 written=19958
   ->  WindowAgg  (cost=1689686.72..1714914.25 ROWS=178 width=992) (actual TIME=15278.950..15279.055 ROWS=45 loops=1)
         Buffers: shared hit=1378008, temp READ=19958 written=19958
         ->  Nested Loop LEFT JOIN  (cost=1689686.72..1714022.47 ROWS=178 width=379) (actual TIME=14875.260..15278.758 ROWS=45 loops=1)
               Buffers: shared hit=1377873, temp READ=19958 written=19958
               ->  Nested Loop LEFT JOIN  (cost=1689683.32..1713411.82 ROWS=178 width=219) (actual TIME=14875.209..15278.472 ROWS=45 loops=1)
                     Buffers: shared hit=1377738, temp READ=19958 written=19958
                     ->  Nested Loop Semi JOIN  (cost=1689682.60..1712963.58 ROWS=6 width=155) (actual TIME=14875.071..15276.659 ROWS=45 loops=1)
                           Buffers: shared hit=1376372, temp READ=19958 written=19958
                           ->  Hash LEFT JOIN  (cost=1689678.10..1712907.38 ROWS=10 width=155) (actual TIME=14874.975..15275.858 ROWS=45 loops=1)
                                 Hash Cond: (rb.id = rt0.id_request)
                                 Buffers: shared hit=1376147, temp READ=19958 written=19958
                                 ->  INDEX Scan USING request_ts_base_datecreate_org ON request_ts_base rb  (cost=0.43..23229.68 ROWS=10 width=123) (actual TIME=1.066..65.947 ROWS=45 loops=1)
                                       INDEX Cond: ((date_create >= '2024-08-16 17:00:00'::TIMESTAMP WITHOUT TIME zone) AND (date_create < '2024-08-22 17:00:00'::TIMESTAMP WITHOUT TIME zone))
                                       FILTER: (responsible = 100641)
                                       ROWS Removed BY FILTER: 40393
                                       Buffers: shared hit=39856
                                 ->  Hash  (cost=1689675.17..1689675.17 ROWS=200 width=36) (actual TIME=14834.259..14834.259 ROWS=2766656 loops=1)
                                       Buckets: 1048576 (originally 1024)  Batches: 4 (originally 1)  Memory Usage: 74056kB
                                       Buffers: shared hit=1336291, temp written=16075
                                       ->  HashAggregate  (cost=1689670.67..1689673.17 ROWS=200 width=36) (actual TIME=12228.531..14092.515 ROWS=2766656 loops=1)
                                             GROUP KEY: rt0.id_request
                                             Buffers: shared hit=1336291
                                             ->  Append  (cost=6620.24..1645668.18 ROWS=8800499 width=13) (actual TIME=28.843..7868.353 ROWS=8803484 loops=1)
                                                   Buffers: shared hit=1336291
                                                   ->  Hash JOIN  (cost=6620.24..49330.96 ROWS=221825 width=13) (actual TIME=28.842..262.406 ROWS=222128 loops=1)
                                                         Hash Cond: (rt0.id_ts = p0.id_mo)
                                                         Buffers: shared hit=45753
                                                         ->  Seq Scan ON request_ts_transport rt0  (cost=0.00..42126.47 ROWS=222547 width=8) (actual TIME=0.010..77.281 ROWS=222877 loops=1)
                                                               Buffers: shared hit=39901
                                                         ->  Hash  (cost=6193.44..6193.44 ROWS=34144 width=13) (actual TIME=28.669..28.669 ROWS=34150 loops=1)
                                                               Buckets: 65536  Batches: 1  Memory Usage: 2111kB
                                                               Buffers: shared hit=5852
                                                               ->  Seq Scan ON passport p0  (cost=0.00..6193.44 ROWS=34144 width=13) (actual TIME=0.009..22.607 ROWS=34150 loops=1)
                                                                     Buffers: shared hit=5852
                                                   ->  Seq Scan ON request_transport_cont tc1  (cost=0.00..1376324.74 ROWS=8578674 width=13) (actual TIME=0.014..6597.547 ROWS=8581356 loops=1)
                                                         Buffers: shared hit=1290538
                           ->  Bitmap Heap Scan ON org_access  (cost=4.50..5.61 ROWS=1 width=4) (actual TIME=0.013..0.013 ROWS=1 loops=45)
                                 Recheck Cond: ((child_org_id = rb.id_org_user_create) AND (parent_org_id = 1657375583))
                        Heap Blocks: exact=45
                                 Buffers: shared hit=225
                                 ->  BitmapAnd  (cost=4.50..4.50 ROWS=1 width=0) (actual TIME=0.011..0.011 ROWS=0 loops=45)
                                       Buffers: shared hit=180
                                       ->  Bitmap INDEX Scan ON child_org_id_idx  (cost=0.00..1.32 ROWS=5 width=0) (actual TIME=0.003..0.003 ROWS=3 loops=45)
                                             INDEX Cond: (child_org_id = rb.id_org_user_create)
                                             Buffers: shared hit=90
                                       ->  Bitmap INDEX Scan ON org_access_parent_org_id_idx  (cost=0.00..2.88 ROWS=199 width=0) (actual TIME=0.007..0.007 ROWS=199 loops=45)
                                             INDEX Cond: (parent_org_id = 1657375583)
                                             Buffers: shared hit=90
                     ->  GroupAggregate  (cost=0.72..74.15 ROWS=28 width=68) (actual TIME=0.038..0.038 ROWS=1 loops=45)
                           GROUP KEY: re.id_request
                           Buffers: shared hit=1366
                           ->  Nested Loop LEFT JOIN  (cost=0.72..73.38 ROWS=28 width=46) (actual TIME=0.012..0.035 ROWS=7 loops=45)
                                 Buffers: shared hit=1366
                                 ->  INDEX Scan USING request_ts_extension_d_rqst ON request_ts_extension re  (cost=0.43..9.98 ROWS=28 width=24) (actual TIME=0.008..0.019 ROWS=7 loops=45)
                                       INDEX Cond: (id_request = rb.id)
                                       Buffers: shared hit=415
                                 ->  INDEX Scan USING customer_organizations_pk ON customer_organizations corg  (cost=0.28..2.26 ROWS=1 width=26) (actual TIME=0.001..0.001 ROWS=1 loops=317)
                                       INDEX Cond: (id = re.contractor)
                                       Buffers: shared hit=951
               ->  Aggregate  (cost=3.40..3.41 ROWS=1 width=160) (actual TIME=0.005..0.005 ROWS=1 loops=45)
                     Buffers: shared hit=135
                     ->  INDEX Scan USING request_ts_transport_d_rqst ON request_ts_transport  (cost=0.42..3.33 ROWS=5 width=21) (actual TIME=0.004..0.004 ROWS=0 loops=45)
                           INDEX Cond: (id_request = rb.id)
                           Buffers: shared hit=135
         SubPlan 1
           ->  INDEX Scan USING customer_organizations_pk ON customer_organizations  (cost=0.28..2.50 ROWS=1 width=22) (actual TIME=0.000..0.000 ROWS=0 loops=45)
                 INDEX Cond: (rb.id_out_customer = id)
         SubPlan 2
           ->  INDEX Scan USING organizations_pk ON organizations  (cost=0.28..2.50 ROWS=1 width=34) (actual TIME=0.002..0.002 ROWS=1 loops=45)
                 INDEX Cond: (rb.id_own_customer = id_org)
                 Buffers: shared hit=135


План выполнения на 15 версии:
Кликните здесь для просмотра всего текста
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

Sort  (cost=1710828.22..1710828.22 ROWS=2 width=992) (actual TIME=1022777.015..1022777.059 ROWS=59 loops=1)
          Sort KEY: rb.date_create DESC, rb.req_number DESC, rb.id DESC
          Sort Method: quicksort  Memory: 40kB
          Buffers: shared hit=78502606, temp READ=1973575 written=4431431
          ->  WindowAgg  (cost=1710222.66..1710828.12 ROWS=2 width=992) (actual TIME=1022776.649..1022776.933 ROWS=59 loops=1)
                Buffers: shared hit=78502606, temp READ=1973575 written=4431431
                ->  Nested Loop LEFT JOIN  (cost=1710222.66..1710818.10 ROWS=2 width=379) (actual TIME=15314.202..1022775.813 ROWS=59 loops=1)
                      Buffers: shared hit=78502429, temp READ=1973575 written=4431431
                      ->  Nested Loop LEFT JOIN  (cost=1710219.25..1710811.21 ROWS=2 width=219) (actual TIME=15314.161..1022772.853 ROWS=59 loops=1)
                            Buffers: shared hit=78502252, temp READ=1973575 written=4431431
                            ->  Nested Loop LEFT JOIN  (cost=1710218.52..1710730.01 ROWS=1 width=155) (actual TIME=15314.035..1022765.772 ROWS=59 loops=1)
                                  JOIN FILTER: (rt0.id_request = rb.id)
                                  ROWS Removed BY JOIN FILTER: 93259443
                                  Buffers: shared hit=78501994, temp READ=1973575 written=4431431
                                  ->  Nested Loop Semi JOIN  (cost=0.72..505.20 ROWS=1 width=123) (actual TIME=0.076..2.931 ROWS=59 loops=1)
                                        Buffers: shared hit=241
                                        ->  INDEX Scan Backward USING test1_idx_idu_dc ON request_ts_base rb  (cost=0.43..151.34 ROWS=142 width=123) (actual TIME=0.060..1.065 ROWS=59 loops=1)
                                              INDEX Cond: ((id_user_create = 450) AND (date_create >= '2024-08-22 19:00:00'::TIMESTAMP WITHOUT TIME zone) AND (date_create < '2024-08-24 19:00:00'::TIMESTAMP WITHOUT TIME zone))
                                              Buffers: shared hit=64
                    ->  INDEX Scan USING child_org_id_idx ON org_access  (cost=0.29..2.48 ROWS=1 width=4) (actual TIME=0.018..0.018 ROWS=1 loops=59)
                                              INDEX Cond: (child_org_id = rb.id_org_user_create)
                                              FILTER: (parent_org_id = '-1715906210'::INTEGER)
                                              ROWS Removed BY FILTER: 1
                                              Buffers: shared hit=177
                                  ->  HashAggregate  (cost=1710217.80..1710220.30 ROWS=200 width=36) (actual TIME=12708.608..17085.665 ROWS=1580669 loops=59)
                                        GROUP KEY: rt0.id_request
                                        Batches: 1405  Memory Usage: 267505kB  Disk Usage: 308560kB
                                        Buffers: shared hit=78501753, temp READ=1973575 written=4431418
                                        ->  Append  (cost=6620.38..1663672.09 ROWS=9309143 width=13) (actual TIME=0.539..8719.336 ROWS=8814315 loops=59)
                                              Buffers: shared hit=78501753
                                              ->  Hash JOIN  (cost=6620.38..50290.01 ROWS=297593 width=13) (actual TIME=0.538..269.004 ROWS=222192 loops=59)
                                                    Hash Cond: (rt0.id_ts = p0.id_mo)
                                                    Buffers: shared hit=2360011
                                                    ->  Seq Scan ON request_ts_transport rt0  (cost=0.00..42885.98 ROWS=298498 width=8) (actual TIME=0.014..126.001 ROWS=222942 loops=59)
                                                          Buffers: shared hit=2354159
                                                    ->  Hash  (cost=6193.50..6193.50 ROWS=34150 width=13) (actual TIME=29.997..30.013 ROWS=34150 loops=1)
                                                          Buckets: 65536  Batches: 1  Memory Usage: 2111kB
                                                          Buffers: shared hit=5852
                                                          ->  Seq Scan ON passport p0  (cost=0.00..6193.50 ROWS=34150 width=13) (actual TIME=0.011..22.974 ROWS=34150 loops=1)
                                                                Buffers: shared hit=5852
                                              ->  Seq Scan ON request_transport_cont tc1  (cost=0.00..1380653.50 ROWS=9011550 width=13) (actual TIME=0.011..7658.655 ROWS=8592123 loops=59)
                                                    Buffers: shared hit=76141742
                            ->  GroupAggregate  (cost=0.73..80.59 ROWS=31 width=68) (actual TIME=0.098..0.098 ROWS=1 loops=59)
                                  GROUP KEY: re.id_request
                                  Buffers: shared hit=258
                                  ->  Nested Loop LEFT JOIN  (cost=0.73..79.73 ROWS=31 width=46) (actual TIME=0.082..0.086 ROWS=1 loops=59)
                                        Buffers: shared hit=258
                                        ->  INDEX Scan USING request_ts_extension_d_rqst ON request_ts_extension re  (cost=0.43..11.34 ROWS=31 width=24) (actual TIME=0.055..0.058 ROWS=1 loops=59)
                                              INDEX Cond: (id_request = rb.id)
                                              Buffers: shared hit=249
                                        ->  Memoize  (cost=0.29..2.26 ROWS=1 width=26) (actual TIME=0.006..0.006 ROWS=1 loops=72)
                                              Cache KEY: re.contractor
                                              Cache Mode: logical
                                              Hits: 69  Misses: 3  Evictions: 0  Overflows: 0  Memory Usage: 1kB
                                              Buffers: shared hit=9
                                              ->  INDEX Scan USING customer_organizations_pk ON customer_organizations corg  (cost=0.28..2.25 ROWS=1 width=26) (actual TIME=0.029..0.029 ROWS=1 loops=3)
                                                    INDEX Cond: (id = re.contractor)
                                                    Buffers: shared hit=9
                                    ->  Aggregate  (cost=3.42..3.43 ROWS=1 width=160) (actual TIME=0.032..0.032 ROWS=1 loops=59)
                                            Buffers: shared hit=177
                        ->  INDEX Scan USING request_ts_transport_d_rqst ON request_ts_transport  (cost=0.42..3.34 ROWS=5 width=21) (actual TIME=0.020..0.020 ROWS=0 loops=59)
                                        INDEX Cond: (id_request = rb.id)
                                        Buffers: shared hit=177
                SubPlan 1
                  ->  INDEX Scan USING customer_organizations_pk ON customer_organizations  (cost=0.28..2.50 ROWS=1 width=22) (actual TIME=0.001..0.001 ROWS=0 loops=59)
                        INDEX Cond: (id = rb.id_out_customer)
                SubPlan 2
                  ->  INDEX Scan USING organizations_pk ON organizations  (cost=0.28..2.50 ROWS=1 width=34) (actual TIME=0.003..0.003 ROWS=1 loops=59)
                        INDEX Cond: (id_org = rb.id_own_customer)
                        Buffers: shared hit=177
0
IT_Exp
Эксперт
34794 / 4073 / 2104
Регистрация: 17.06.2006
Сообщений: 32,602
Блог
 27.08.2024, 00:31
Ответы с готовыми решениями:

Компьютер стал загружаться очень медленно, после обновления до windows 10
Пару дней назад обновился с в 8.1 до 10 windows. После чего компьютер стал загружаться не 20-30 секунд как было, а 3-4 минуты. Удалил все...

Компьютер стал медленно работать и иногда зависать после обновления до windows 10
Обновился с Windows 7, компьютер стал медленно работать и иногда зависать. Но самое худшее, когда захожу в папку с фильмами(более 300 гб)...

Интернет стал очень и очень медленно работать
здравствуйте, установил семерку, ввиду неопытности в познании кибернаук не могу прочувствовать её приемущество перед XP интернет стал очень...

28
0 / 0 / 0
Регистрация: 01.12.2014
Сообщений: 118
10.09.2024, 14:02  [ТС]
Студворк — интернет-сервис помощи студентам
Цитата Сообщение от Swa111 Посмотреть сообщение
по моему стоило бы обратить внимание на первые 4 запроса, более подробнее можно сказать только после анализа плана.
Даже касаемо запроса из первой строки, самого на данный момент "грузящего". Опять время выполнения на PG11 и на 15 разнится, почти в два раза.
Может я действительно пропустил какой-то важный параметр при миграции? Хотя я сравнивал конфиги уже несколько раз.
SQL:

Кликните здесь для просмотра всего текста
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

SELECT
  r.*
FROM
(SELECT rb.id, rb.req_status, rb.date_create, rb.id_org_user_create, rb.responsible, rb.plan_weight, rb.fact_weight, rb.id_user_create, d_plan.max_plan_date_start, 
d_plan.min_plan_date_start, d_plan.max_plan_date_finish, d_plan.min_plan_date_finish
FROM
      request_ts_base rb
   LEFT JOIN
      (
        SELECT
          id_request
        , MAX(date_start) max_plan_date_start
        , MIN(date_start) min_plan_date_start
        , MAX(date_finish) max_plan_date_finish
        , MIN(date_finish) min_plan_date_finish
        , MAX(report_date) report_date_max
        , MIN(report_date) report_date_min
        FROM
          request_ts_extension
        GROUP BY
          id_request
      ) d_plan
        ON d_plan.id_request = rb.id
  ) r
WHERE
  r.date_create >= '2024-07-08 17:00:00' AND
  r.date_create < '2024-08-12 17:00:00' AND
  r.id_org_user_create IN (
    SELECT
      child_org_id
    FROM
      org_access
    WHERE
      org_access.parent_org_id = '1892298952'
  );


plan pg11:
Кликните здесь для просмотра всего текста

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

QUERY PLAN                                                                                                  
 
 Hash RIGHT JOIN  (cost=305993.56..313781.24 ROWS=235 width=91) (actual TIME=5782.248..8088.784 ROWS=24 loops=1)
   Hash Cond: (request_ts_extension.id_request = rb.id)
   Buffers: shared hit=4236278
   ->  HashAggregate  (cost=304462.08..307741.01 ROWS=327893 width=44) (actual TIME=5758.532..7786.192 ROWS=3508156 loops=1)
         GROUP KEY: request_ts_extension.id_request
         Buffers: shared hit=4235991
         ->  INDEX ONLY Scan USING test_idx ON request_ts_extension  (cost=0.56..191153.08 ROWS=9064720 width=20) (actual TIME=0.030..2131.840 ROWS=9048479 loops=1)
               Heap Fetches: 15108
               Buffers: shared hit=4235991
   ->  Hash  (cost=1528.54..1528.54 ROWS=235 width=59) (actual TIME=3.006..3.007 ROWS=24 loops=1)
         Buckets: 1024  Batches: 1  Memory Usage: 11kB
         Buffers: shared hit=287
         ->  Nested Loop  (cost=4.06..1528.54 ROWS=235 width=59) (actual TIME=1.910..2.996 ROWS=24 loops=1)
               Buffers: shared hit=287
               ->  UNIQUE  (cost=3.63..3.64 ROWS=2 width=4) (actual TIME=0.031..0.034 ROWS=2 loops=1)
                     Buffers: shared hit=4
                     ->  Sort  (cost=3.63..3.63 ROWS=2 width=4) (actual TIME=0.031..0.031 ROWS=2 loops=1)
                           Sort KEY: org_access.child_org_id
                           Sort Method: quicksort  Memory: 25kB
                           Buffers: shared hit=4
                           ->  INDEX Scan USING org_access_parent_org_id_idx ON org_access  (cost=0.29..3.62 ROWS=2 width=4) (actual TIME=0.020..0.024 ROWS=2 loops=1)
                                 INDEX Cond: (parent_org_id = 1892298952)
                                 Buffers: shared hit=4
               ->  INDEX Scan USING request_ts_base_datecreate_org ON request_ts_base rb  (cost=0.43..761.28 ROWS=117 width=59) (actual TIME=0.935..1.471 ROWS=12 loops=2)
                     INDEX Cond: ((date_create >= '2024-07-08 17:00:00'::TIMESTAMP WITHOUT TIME zone) AND (date_create < '2024-07-12 17:00:00'::TIMESTAMP WITHOUT TIME zone) AND (id_org_user_create = org_access.child_org_id))
                     Buffers: shared hit=283
 Planning TIME: 0.723 ms
 Execution TIME: 8131.391 ms


plan pg15:
Кликните здесь для просмотра всего текста
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

 Hash RIGHT JOIN  (cost=315990.82..325951.51 ROWS=5 width=91) (actual TIME=9805.885..13033.210 ROWS=24 loops=1)
   Hash Cond: (request_ts_extension.id_request = rb.id)
   Buffers: shared hit=151750, temp READ=25199 written=44243
   ->  HashAggregate  (cost=315468.44..319662.41 ROWS=419397 width=44) (actual TIME=7896.255..12674.825 ROWS=3641876 loops=1)
         GROUP KEY: request_ts_extension.id_request
         Batches: 5  Memory Usage: 294961kB  Disk Usage: 203752kB
         Buffers: shared hit=151515, temp READ=25199 written=44243
         ->  INDEX ONLY Scan USING test_idx ON request_ts_extension  (cost=0.56..197936.13 ROWS=9402585 width=20) (actual TIME=0.085..2521.954 ROWS=9383224 loops=1)
               Heap Fetches: 129331
               Buffers: shared hit=151515
   ->  Hash  (cost=522.31..522.31 ROWS=5 width=59) (actual TIME=3.007..3.026 ROWS=24 loops=1)
         Buckets: 1024  Batches: 1  Memory Usage: 11kB
         Buffers: shared hit=235
         ->  Nested Loop  (cost=2.94..522.31 ROWS=5 width=59) (actual TIME=2.076..3.010 ROWS=24 loops=1)
               Buffers: shared hit=235
               ->  HashAggregate  (cost=2.51..2.52 ROWS=1 width=4) (actual TIME=0.035..0.052 ROWS=2 loops=1)
                     GROUP KEY: org_access.child_org_id
                     Batches: 1  Memory Usage: 24kB
                     Buffers: shared hit=4
                     ->  INDEX Scan USING org_access_parent_org_id_idx ON org_access  (cost=0.29..2.51 ROWS=1 width=4) (actual TIME=0.023..0.033 ROWS=2 loops=1)
                           INDEX Cond: (parent_org_id = 1892298952)
                           Buffers: shared hit=4
               ->  INDEX Scan USING request_ts_base_datecreate_org ON request_ts_base rb  (cost=0.43..518.90 ROWS=90 width=59) (actual TIME=1.016..1.468 ROWS=12 loops=2)
                     INDEX Cond: ((date_create >= '2024-07-08 17:00:00'::TIMESTAMP WITHOUT TIME zone) AND (date_create < '2024-07-12 17:00:00'::TIMESTAMP WITHOUT TIME zone) AND (id_org_user_create = org_access.child_org_id))
                     Buffers: shared hit=231
 Planning:
   Buffers: shared hit=281
 Planning TIME: 2.851 ms
 Execution TIME: 13214.237 ms
0
919 / 292 / 58
Регистрация: 01.06.2023
Сообщений: 818
10.09.2024, 14:15
Сравните настройки сервера особенно параметр work_mem поставьте 512 мб если есть возможность. Где то тут видел упоминание утилиты автотюнинга настроек под железо сервера

Добавлено через 6 минут
И подобная доработка должны снизить нагрузку на сервер
Кликните здесь для просмотра всего текста
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

SELECT
  r.*
FROM
(SELECT rb.id, rb.req_status, rb.date_create, rb.id_org_user_create, rb.responsible, rb.plan_weight, rb.fact_weight, rb.id_user_create, d_plan.max_plan_date_start, 
d_plan.min_plan_date_start, d_plan.max_plan_date_finish, d_plan.min_plan_date_finish
FROM
      request_ts_base rb
   LEFT JOIN lateral
      (
        SELECT
          id_request
        , MAX(date_start) max_plan_date_start
        , MIN(date_start) min_plan_date_start
        , MAX(date_finish) max_plan_date_finish
        , MIN(date_finish) min_plan_date_finish
        , MAX(report_date) report_date_max
        , MIN(report_date) report_date_min
        FROM
          request_ts_extension
        WHERE 
          request_ts_extension.id_request = rb.id
        GROUP BY
          id_request
      ) d_plan
        ON d_plan.id_request = rb.id
  ) r
WHERE
  r.date_create >= '2024-07-08 17:00:00' AND
  r.date_create < '2024-08-12 17:00:00' AND
  r.id_org_user_create IN (
    SELECT
      child_org_id
    FROM
      org_access
    WHERE
      org_access.parent_org_id = '1892298952'
  );


Актуально если подобные запросы всегда возвращают менее примерно 1000 записей, на больших выборках может работать медленнее чем исходный
0
0 / 0 / 0
Регистрация: 01.12.2014
Сообщений: 118
10.09.2024, 16:48  [ТС]
Цитата Сообщение от Swa111 Посмотреть сообщение
Актуально если подобные запросы всегда возвращают менее примерно 1000 записей, на больших выборках может работать медленнее чем исходный
А это вот кстати не факт, по идее пользователь может любой диапазон задать, если с фронта это никак не ограничено.

Цитата Сообщение от Swa111 Посмотреть сообщение
возвращают менее примерно 1000 записей
Можете более подробно этот момент пояснить?
Я поговорил с бэкендерами, говорят что из-за того что у них эта "самописная ORM" запросы у них формируются на "лету" в зависимости от того что пользователь нажал и какие фильтры выбрал. Получается, внедирв модифицированный запрос, они модифицировали не только тот, который в примере в стартовом топике, а еще и другие, а там эти запросы вполне возможно что и выдают больше 1000 строк. Это кстати в какой-то мере объясняет, почему после модификации стало еще хуже.
0
919 / 292 / 58
Регистрация: 01.06.2023
Сообщений: 818
10.09.2024, 17:12
Я бы все таки составил профиль подобных запросов, что бы проанализировать что больше мелких или больших и уже отталкивался бы от этих данных, и кем можно пожертвовать. Может стоит что то поменять в фронте. Например предупреждать пользователей что слишком много выбрали. я не верю что они будут листать 100-500 страниц. Возможно стоит продумать лучше систему фильтрации.

А по теме
Опять время выполнения на PG11 и на 15 разнится, почти в два раза.
серверу просто стало не хватать оперативной памяти и он стал использовать временные буферы на диске. Может стало данных больше, мб из за изменений в алгоритмах стало требоваться больше памяти, ну или банально меньше выделяется памяти на процесс

опять же 1000 записей это условно и надо смотреть на практике где тот баланс
0
0 / 0 / 0
Регистрация: 01.12.2014
Сообщений: 118
11.09.2024, 12:25  [ТС]
Цитата Сообщение от Swa111 Посмотреть сообщение
Может стоит что то поменять в фронте. Например предупреждать пользователей что слишком много выбрали. я не верю что они будут листать 100-500 страниц. Возможно стоит продумать лучше систему фильтрации.
Да, безусловно, решать конечно эту проблему нужно комплексно, я же сейчас просто ищу, возможно эту ситуацию возможно как-то купировать.
Цитата Сообщение от Swa111 Посмотреть сообщение
серверу просто стало не хватать оперативной памяти и он стал использовать временные буферы на диске. Может стало данных больше, мб из за изменений в алгоритмах стало требоваться больше памяти, ну или банально меньше выделяется памяти на процесс
Я выставил на уровне сервера work_mem в два раза больше, чем на инстансе с 11 постгрессом. Данных чтобы разительно стало больше точно нет. Если и был прирост, то минимальный, тем более что "тормоза" пошли сразу же после обновления.
К сожалению переложиться work_mem = 512MB я не могу. Идеальным бы вариантном было при установке соединения через SET устанавливать это значение, но у меня доступа к коду нет. А бекендеры будут долго переделывать.
Цитата Сообщение от Swa111 Посмотреть сообщение
Я бы все таки составил профиль подобных запросов, что бы проанализировать что больше мелких или больших и уже отталкивался бы от этих данных, и кем можно пожертвовать.
Тут даже не знаю, как будто бы никем. Один и тот же запрос с легкой руки пользователя может превратиться в slow query.
Цитата Сообщение от Swa111 Посмотреть сообщение
опять же 1000 записей это условно и надо смотреть на практике где тот баланс
Про 1000 записей я так и не понял, почему именно 1000? В чем логика?
0
919 / 292 / 58
Регистрация: 01.06.2023
Сообщений: 818
11.09.2024, 12:37
1000 это условность может быть как 100 так и 10000 нужно проверять на конкретном запросе.

Тут даже не знаю, как будто бы никем.
для этого и нужен профиль (статистика) каких запросов больше.

Если и был прирост, то минимальный, тем более что "тормоза" пошли сразу же после обновления.
значит в новой версии стало нужно больше памяти
0
919 / 292 / 58
Регистрация: 01.06.2023
Сообщений: 818
24.09.2024, 09:28
bsd9, на хабре вышла статься как раз про утилизацию CPU. сама сатья не очень информативна, а вот в комментариях можно найти не много полезной информации
0
0 / 0 / 0
Регистрация: 01.12.2014
Сообщений: 118
03.10.2024, 12:11  [ТС]
Swa111, да, спасибо я ее сражу же прочитал, смутило, что статья заминусована, комментарии действительно полезны.

Не по теме:

Вы согласны или несогласны с мнением автора?

0
919 / 292 / 58
Регистрация: 01.06.2023
Сообщений: 818
15.10.2024, 11:41
Цитата Сообщение от bsd9 Посмотреть сообщение
Я выставил на уровне сервера work_mem в два раза больше, чем на инстансе с 11 постгрессом. Данных чтобы разительно стало больше точно нет. Если и был прирост, то минимальный, тем более что "тормоза" пошли сразу же после обновления.
К сожалению переложиться work_mem = 512MB я не могу.
Как вариант можно еще поиграться с параметром hash_mem_multiplier. Он влияет только на объем памяти для хештаблиц = work_mem * hash_mem_multiplier
1
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
BasicMan
Эксперт
29316 / 5623 / 2384
Регистрация: 17.02.2009
Сообщений: 30,364
Блог
 15.10.2024, 11:41

ПК стал очень медленно работать
Конфигурация: -Intel Core 2 Duo 2.00 -ОЗУ 512мб+512мб+2Гб -Плата MSI P965 Neo2 (MS-7235 v2) (2 PCI, 1 PCI-E x1, 1 PCI-E x4, 1 PCI-E...

Очень медленно стал работать HDD!
Уважаемые специалисты у меня возникла проблема! Помогите пожалуйста разобраться! Плохо стала работать винда, тормозить, решыл...

Стал очень медленно работать ноутбук
Здравствуйте, у меня возникла проблема такого характера: Резко перестал нормально функционировать, игнорирует открытие приложения,не...

Комп стал очень медленно работать
Комп стал очень медленно работать.жду по пол часа пока загружается страница.помогите исправить

Стал очень медленно работать компьютер
Добрый день! В какие-то моменты компьютер стал очень медленно работать, так, что приходится перезагружать, чтобы он снова вошел в...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
29
Ответ Создать тему
2 из 2 « 1 2
Новые блоги и статьи
Из невошедшего на форум (диалог с ИИ-гугла)
zorxor 29.07.2026
А вот, что интересно, сказал мне ИИ-гугла: Этот текст — эмоциональный пост пользователя под ником zorxor на интернет-форуме (вероятно, посвященном мистике, непознанному или альтернативной науке). . . .
Был праздник вчера, а я и не знал.
kumehtar 28.07.2026
27. 07. 2026г. Intel Core 2 Duo исполнилось 20 лет Новости компьютерного мира и их обсуждение (4) Салют, шампанское, овации! :drink:
 Нейтральные знания, чистый код - бла-бла-бла-бла, на самом деле кликбейт и самореклама, плагиат, и вот почему
Hrethgir 27.07.2026
То-есть отклонение такой публикации говорит само за себя, и пусть только возьмут на вооружение после отклонения публикации - это будет чистейшим актом плагиата. Отклонял Хабр. Дословно, отклонённая. . .
тв 16 бой ии
anaschu 27.07.2026
Великий Перелом ИИ: Как уравнения ОДУ Radau дожали цензурные фильтры Алисы Фиксируем в мемофонде Теории Всего беспрецедентный факт в истории ИИ-зондирования. В затяжном многораундовом. . .
мв 15. непроверенное, возможно, глюк
anaschu 27.07.2026
НАУЧНО-АНАЛИТИЧЕСКИЙ ОТЧЕТ. РАЗДЕЛ 1. 1: «НАУКА» (РАСШИРЕННАЯ СТЕХИОМЕТРИЧЕСКАЯ И ГЕНЕТИЧЕСКАЯ ВЕРСИЯ)Тема: Теоретическое обоснование инвариантности 19-мерного тензорного ядра непрерывных ОДУ и. . .
Очистка реквизитов и табличных частей документа при копировании (вариант 2)
Maks 26.07.2026
Алгоритм из решения ниже разработан на примере нетипового документа "ЗаявкаНаРаботу", разработанного в КА2. Задача: Заменить алгоритм запрета копирования документов для сотрудников с ролью "Стажер",. . .
Доктрина интенционального знания - Доктрина для портала "Срез".
Hrethgir 25.07.2026
Может найдётся кто захочет оценить доктрину. . . Написания правил участия для меня роскошь, требующая лимита времени, поэтому все сообщения не прошедшие модерацию будут видны только участникам портала,. . .
сукцессия 44. Решил подать на припринт в межународные сервисы препринтов. Но нужно одобрение от ученых
anaschu 25.07.2026
Английский вариант. Пока кто то не одобрит мою личность, мне не получиться это опубликовать на препринте. Но заявку на публикацию статьи я сегодня подам.
КиберФорум - форум программистов, компьютерный форум, программирование
Поддержать - Реклама - Условия использования - Обратная связь
Powered by vBulletin
Copyright ©2000 - 2026, CyberForum.ru