Привет. Мы тут столкнулись с тем, что count(*) с where

Question

Привет. Мы тут столкнулись с тем, что count(*) с where

отрабатывает долго. В таблице около 6 лямов записей. Кто-то сталкивался с таким? Как решали? Вариант с добавлением в бд поля, которое будет инкрементить при добавлении новой записи - не подходит

Вот, что выводит explain
```
Finalize Aggregate (cost=301225.75..301225.76 rows=1 width=8)
-> Gather (cost=301225.54..301225.75 rows=2 width=8)
Workers Planned: 2
-> Partial Aggregate (cost=300225.54..300225.55 rows=1 width=8)
-> Parallel Seq Scan on tradingbot_logs (cost=0.00..296510.03 rows=1486203 width=0)
Filter: (((event_type)::text <> 'candle_data_received'::text) OR (event_type IS NULL))
JIT:
Functions: 6
" Options: Inlining false, Optimization false, Expressions true, Deforming true"
```

#backend #devops #pgsql #programming #russian

0

05.11.2021

5 ответов

5 просмотров

Ilya Anfimov

Ну, добавьте два поля, которых будут инкрементить при добавлении новой записи, делов-то.

0

05.11.2021

Не выходи из комнаты. Автор вопроса

Ilya Anfimov
Ну, добавьте два поля, которых будут инкрементить ...

не вариант

0

05.11.2021

Ilya Anfimov

Не выходи из комнаты.
не вариант

Тогда страдать. ЗЫ Нет, то есть можно было бы подумать если бы ты нормально поставил задачу. А вот эти все -- не вариант -- ну раз ты такой умный, то думай сам.

0

05.11.2021

Не выходи из комнаты. Автор вопроса

Угу. Хотелось бы.

0

05.11.2021

alex che · Accepted Answer

Все сталкивались. Сделать ничего нельзя, потому что 1) условие у вас такое, что под него подходит больше полтаблицы, поэтому выбранный способ Parallel Seq Scan — правильный 2) даже если подпереть конкретный фильтр индексом, то всё равно надо лазать в таблицу и перепроверять из-за MVCC Вот если вам нужно лишь приблизительное значение — тогда есть способы. Ну и есть способ с подсчётом в триггере, о котором вы упомянули

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

Привет. Мы тут столкнулись с тем, что count(*) с where

5 ответов

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