Вечер добрый, возвращаюсь с проблемой. Постгрес не использует индексы при

большой выборке, из-за этого запросы выполняются критически долго а на реплике более 15 мин нельзя выполнять запрос.
Например, если выбирать данные за последние 15 дней, то используется индекс по дате, а если за 30, то нет.
Как решить такое? Слышал что можно хинтить, поможет ли это?

Можно попробовать хинт set enable_seqscan=off, посмотреть, будет ли использовать индекс и каким результатом.

не поменялось

Показали бы Вы (всё текстом!) запрос, версию PostgreSQL, \d каждой таблицы в запросе, и EXPLAIN (ANALYZE, BUFFERS) "быстрого" варианта (за 15 дней), и EXPLAIN медленного.

запрос SELECT email, last_played FROM (SELECT accounts."email", COUNT(buff_transactions.id) AS total, MAX(buff_transactions."createdAt") AS last_played FROM accounts LEFT JOIN buff_transactions ON accounts.id = buff_transactions."recipientId" AND buff_transactions.type = 2 AND buff_transactions."createdAt" > now() - interval '20 days' GROUP BY accounts."email" offset 0) AS t WHERE total != 0 AND last_played < now() - interval '7 days'; Эксплнейн Subquery Scan on t (cost=167562.51..171432.06 rows=42780 width=31) Filter: ((t.total <> 0) AND (t.last_played < (now() - '7 days'::interval))) -> Finalize HashAggregate (cost=167562.51..168852.36 rows=128985 width=39) Group Key: accounts.email -> Gather (cost=138540.89..165627.74 rows=257970 width=39) Workers Planned: 2 -> Partial HashAggregate (cost=137540.89..138830.74 rows=128985 width=39) Group Key: accounts.email -> Nested Loop Left Join (cost=0.56..136371.34 rows=155940 width=47) -> Parallel Seq Scan on accounts (cost=0.00..9448.44 rows=53744 width=39) -> Index Scan using buff_transactions_recipient_fkey on buff_transactions (cost=0.56..2.35 rows=1 width=40) Index Cond: ("recipientId" = accounts.id) Filter: ((type = 2) AND ("createdAt" > (now() - '20 days'::interval))) (13 rows) Эксплейн аналайз бафферс за 15 дней Subquery Scan on t (cost=139155.47..143025.02 rows=42780 width=31) (actual time=9780.963..9825.538 rows=3348 loops=1) Filter: ((t.total <> 0) AND (t.last_played < (now() - '7 days'::interval))) Rows Removed by Filter: 125640 Buffers: shared hit=479788 read=95954 I/O Timings: read=8836.105 -> HashAggregate (cost=139155.47..140445.32 rows=128985 width=39) (actual time=9780.954..9816.607 rows=128988 loops=1) Group Key: accounts.email Buffers: shared hit=479788 read=95954 I/O Timings: read=8836.105 -> Hash Right Join (cost=11813.60..137421.06 rows=231255 width=47) (actual time=372.716..9560.720 rows=458578 loops=1) Hash Cond: (buff_transactions."recipientId" = accounts.id) Buffers: shared hit=479788 read=95954 I/O Timings: read=8836.105 -> Index Scan using buff_transactions_created_idx on buff_transactions (cost=0.44..125000.85 rows=231255 width=40) (actual time=1.980..9005.140 rows=341507 loops=1) Index Cond: ("createdAt" > (now() - '15 days'::interval)) Filter: (type = 2) Rows Removed by Filter: 626978 Buffers: shared hit=479610 read=87218 I/O Timings: read=8537.989 -> Hash (cost=10200.85..10200.85 rows=128985 width=39) (actual time=367.798..367.800 rows=128988 loops=1) Buckets: 131072 Batches: 1 Memory Usage: 10027kB Buffers: shared hit=178 read=8733 I/O Timings: read=296.680 -> Seq Scan on accounts (cost=0.00..10200.85 rows=128985 width=39) (actual time=0.611..332.748 rows=128988 loops=1) Buffers: shared hit=178 read=8733 I/O Timings: read=296.680 Planning Time: 13.482 ms Execution Time: 9826.945 ms (28 rows)

Я написал: 1) запрос, 2) версию PostgreSQL, 3) \d каждой таблицы в запросе, и 4) EXPLAIN (ANALYZE, BUFFERS) "быстрого" варианта (за 15 дней), и 5) EXPLAIN медленного Неужели так трудно (всё равно к этому придёт, скорее всего)?

а зачем так? WHERE total != 0 AND last_played < now() - interval '7 days' а не having MAX(buff_transactions."createdAt")< now() - interval '7 days' and COUNT(buff_transactions.id)<>0 ?

А зачем запрос уже за-hint-ован, кстати? GROUP BY accounts."email" OFFSET 0

просто проверял как отработает с оффсетом 0

действительно, поменяю сейчас