с where col = ‘x’, то индекс используется. А если where col in (‘x’, ‘y’) то используется сек скан с фильтром, индекс не используется. Почему так и как заставить использовать индекс?
https://t.me/pgsql/303899
1. 13.5 2. select * from subscription_events where ((created_at >= '2021-11-01 00:00:00'::timestamp without time zone) AND (created_at <= '2022-02-03 23:59:59.999999'::timestamp without time zone)) and ("subscription_events"."kind" in ('trial_started', 'billing_issue_resolved')) and app_id = '18d7814d-29a1-470d-be31-47a22a86d89e' ORDER BY "subscription_events"."created_at" DESC limit 3000; 3. на скрине 4. на скрине
Постить текст скриншотами — это издевательство.
Впрочем, надо заметить во-первых, что он очень сильно ошыбается с селективностью запроса. Три порядка. Это можно попробовать исправить либо ппосто прогнав analyze либо подняв statistic_target всякий.
Далее, он зачем-то превращает kind из varchar в text. Я не уверен, что это — причина того, что он не делает index-only scan хотя бы, но... Возможно, это проблема. Попробуйте привести это жёстко к varchar. По-моему, он и так должэн бы внутри понимать, что можно использовать индэкс на varchar, когда подаётся text, плюс он скорее должэн начать вычисление типов any() с определённых — потому вывести varchar. Цэлых два странных поведения... Но какие есть пока. Видимо, на тэстирование varchar совсем забили, к сожалению.
Подскажите где вы увидели инфо об ошибке селективности запроса?
Ну, и индэкс (created_at, app_id, kind) — хорош, чтобы не делать отдельный индэкс created_at для запросов, в которых не нужэн app_id хотя бы — и плох примерно во всём остальном. Для этого-то запроса лучшэ app_id и kind вперёд поставить. Или хотя бы один app_id.
Index scan backward ожыдает 30 с чем-то тысяч строк, получает 18. И да, ошыбка не в селективности запроса — а в оцэнке её оптимизитором.
И да, проверить, что проблема связана с типами и text/varchar — смени any на (kind='...' or kind='...).
Обсуждают сегодня