таблицу с 50 млн на 19 штук по месяцам (правда вышло с 15 числа по 15, а, не с 1 по 1, но это тут роли не играет же, насколько я понимаю?)
SELECT create_range_partitions('table', 'date', '2015-09-15'::date, '1 month'::interval);
и в итоге все запросы выполняются намного медленее и даже простой count по конкретной дате очень долгий
zz7=# explain analyze select count(*) from transactions where trans_date='2017-03-02';
QUERY PLAN
Aggregate (cost=8891.82..8891.83 rows=1 width=8) (actual time=36996.932..36996.933 rows=1 loops=1)
-> Append (cost=0.43..8681.65 rows=84066 width=0) (actual time=0.027..36978.710 rows=80796 loops=1)
-> Index Only Scan using transactions_18_trans_date_idx on transactions_18 (cost=0.43..8681.65 rows=84066 width=0) (actual time=0.025..36951.611 rows=80796 loops=1)
Index Cond: (trans_date = '2017-03-02'::date)
Heap Fetches: 80796
Planning time: 0.198 ms
Execution time: 36996.964 ms
(7 rows)
Time: 36997.581 ms
индекс используется, в чем дело, почему так долго, может при создании нужно было параметры указать или в конфиге пострес что-то поменять? свободной оперативки на сервере гига 4, если это важно
ну тут пафман не работает, вы только разделили таблицу с помощью него. А тот же запрос на непартицированной таблице был быстрее?
Меня смущает heap fetches 80796. У вас из индекса вытаскивается 84066 строк и потом запрос идёт в таблицу и почти все перепроверяет. Конечно, это долго. Попробуйте сделать vacuum freeze на партицию и посмотрите, как изменится heap fetches в плане запроса (ну и скорость)
Обсуждают сегодня