Skip to content

Long planning time #199

Closed
Closed
@thamerlan

Description

@thamerlan

Привет.
Сегодня начало очень сильно проседать время планирования запроса для одной из таблиц. CPU usage вырос с 10 до 70% на 64 ядерной машине. Одномоментно идёт порядка 30-50 запросов в секунду к этой таблице.

EXPLAIN ANALYZE
SELECT *
FROM
   r_history
WHERE
       started_at >= '2019-05-23T10:16:41.000Z'
   AND started_at <= '2019-05-23T10:17:41.999Z'
ORDER BY
   started_at DESC
LIMIT 100
;

QUERY PLAN                                                                                        
 Limit  (cost=0.57..4.19 rows=1 width=2417) (actual time=0.015..0.015 rows=0 loops=1)
   ->  Append  (cost=0.57..4.19 rows=1 width=2417) (actual time=0.014..0.014 rows=0 loops=1)
         ->  Index Scan Backward using r_history_1162_started_at_idx on r_history__190520_190527  (cost=0.57..4.19 rows=1 width=127) (actual time=0.013..0.013 rows=0 loops=1)
               Index Cond: ((started_at >= '2019-05-23 10:16:41'::timestamp without time zone) AND (started_at <= '2019-05-23 10:17:41.999'::timestamp without time zone))
 Planning time: 1258.609 ms
 Execution time: 0.065 ms
(6 rows)

Если убрать одно из двух условий по started_at (например оставить только "started_at >= '2019-05-23T10:16:41.000Z'"), то время планирования в два раза меньше.

Если убрать из выборки WHERE целиком, то планирование отрабатывает моментально:

QUERY PLAN                                                                                                  
 Limit  (cost=0.57..4.84 rows=100 width=2417) (actual time=486.490..486.599 rows=100 loops=1)
   ->  Append  (cost=0.57..489013381.31 rows=11463915387 width=2417) (actual time=486.488..486.573 rows=100 loops=1)
         ->  Index Scan Backward using r_history_1162_started_at_idx on r_history__190520_190527  (cost=0.57..6385692.61 rows=151484656 width=127) (actual time=486.486..486.563 rows=100 loops=1)
         ....
         ->  Index Scan Backward using idx_r_history_92_started_at on r_history_92  (cost=0.57..10321319.97 rows=242170880 width=237) (never executed)
 Planning time: 10.132 ms
 Execution time: 487.204 ms
(44 rows)

Другие сегментированные таблицы работают нормально (даже с бОльшим кол-вом секций и данных).
Ничего принципиального сегодня не меняли: неделю обратно добавили два новых NULLable поля; сегодня удалили около 60 секций из 100, но уже после начала тормозов.

Прошу помощи.

Environment

  extname       | extowner | extnamespace | extrelocatable | extversion |    extconfig    | extcondition 

--------------------+----------+--------------+----------------+------------+-----------------+--------------
plpgsql | 10 | 11 | f | 1.0 | |
pg_hashids | 10 | 2200 | t | 1.2.1 | |
pg_repack | 10 | 2200 | f | 1.4.3 | |
dblink | 10 | 2200 | t | 1.2 | |
pg_pathman | 10 | 2200 | f | 1.4 | {158084,158095} | {"",""}
pg_stat_statements | 10 | 2200 | t | 1.5 | |
pgcrypto | 10 | 2200 | t | 1.3 | |
pglogical | 10 | 157990 | f | 2.2.0 | |
postgres_fdw | 10 | 2200 | t | 1.0 | |
uuid-ossp | 10 | 2200 | t | 1.1 | |
pg_cron | 16907 | 158034 | f | 1.1 | |
(11 rows)

PostgreSQL 10.5 (Ubuntu 10.5-2.pgdg16.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609, 64-bit

SELECT get_pathman_lib_version();

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions