Впринципе, пока мы общались, я попробовал просто добавить индекс

Question

Впринципе, пока мы общались, я попробовал просто добавить индекс

на sending_status и запрос отработал за 340мс.

Index Scan using http_history_sending_time_index on history (cost=0.43..13.09 rows=108 width=246) (actual time=0.319..0.319 rows=0 loops=1)
Index Cond: (sending_status = 'InProgress'::call_status)
Filter: (sending_time <= '2019-08-05 15:49:52.95707+00'::timestamp with time zone)
Rows Removed by Filter: 372
Buffers: shared hit=295
Planning time: 0.112 ms
Execution time: 0.338 ms

Sending status - это enum из 4 занчений, и у 99% строк это значение какраз не равно InProgress, который я ищу в запросе. Уместно ли в таком случае держать индекс (btree)?

Новые строки в таблицу добавляются 2-20 раз в секунду

#backend #devops #pgsql #programming #russian

0

05.08.2019

1 ответов

13 просмотров

Yaroslav Schekin · Accepted Answer

Тот, который я предлагал, мог бы быть ещё [немного] лучше, в принципе (смотря сколько записей отфильтровывает условие по sending_time). > Уместно ли в таком случае держать индекс (btree)? Уместно сделать conditional index, в таком случае: CREATE INDEX ON history(sending_time) WHERE sending_status = 'InProgress'; > Если честно, то это были "тыки" пальцем в небо Вот и убрали бы Вы его, он Вам только всё портит, почти наверняка.

172 похожих чатов

Впринципе, пока мы общались, я попробовал просто добавить индекс

1 ответов

Похожие вопросы