отрабатывает долго. В таблице около 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"
```
Все сталкивались. Сделать ничего нельзя, потому что 1) условие у вас такое, что под него подходит больше полтаблицы, поэтому выбранный способ Parallel Seq Scan — правильный 2) даже если подпереть конкретный фильтр индексом, то всё равно надо лазать в таблицу и перепроверять из-за MVCC Вот если вам нужно лишь приблизительное значение — тогда есть способы. Ну и есть способ с подсчётом в триггере, о котором вы упомянули
Ну, добавьте два поля, которых будут инкрементить при добавлении новой записи, делов-то.
Тогда страдать. ЗЫ Нет, то есть можно было бы подумать если бы ты нормально поставил задачу. А вот эти все -- не вариант -- ну раз ты такой умный, то думай сам.
Угу. Хотелось бы.
Обсуждают сегодня