Long planning time

[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();

[thamerlan]

SELECT get_pathman_lib_version();
get_pathman_lib_version

1.4.12

[thamerlan]

Закрываю тикет. Проблема не связана с pathman.
Сам postgres виноват. В крайней секции было удалено около 2% данных с конца таблицы. Видимо такая "дырка" в конце таблицы как-то влияет на планировщик. vacuum freeze помог.