и есть на app_id+kind+created_at (для соответственных фильтров)
Я делаю запрос фильтруя по created_at и app_id. с лимитом 30, сорт по created_at desc. планнер ожидает 17662 рядов и юзает app_id+kind+created_at индекс, в три воркера отрабатывает быстро. всё нормально
и тут прикол. Ставлю лимит 20 - все оценки те же самые, но теперь он использует индекс на created_at и фильтрует по app_id. Rows Removed by Filter: 19240845. выполняется несколько минут.
Че за чудеса? Как думаете почему так? Какой лучше набор индексов тут использовать (часто фильтруем по created_at+app_id, created_at+app_id+kind, app_id, kind, app_id+kind)
а сколько всего записей при этом возвращается с лимитом 30?
1) Очевидный индэкс при поиске по appt_id, created_at -- это (appt_id, created_at). Обратный вариант -- (created_at, app_id) -- гораздо хужэ, поскольку created_at скорее всего будет диапазон -- и просматривать он по факту будет практически все страницы индэкса из данного диапазона. Но! Дажэ обратный вариант будет, скорее всего, гораздо лучшэ чем у вас есть -- поскольку просматривать он будет только индэкс, не обращаясь по каждой записи в таблицу. 2) https://t.me/pgsql/303899
3) Тут, кстати, опять проявляется проблема с коррелированными колонками. Что если бы app_id и created_at были равномерно распределены друг по другу -- то выбрал бы какие-то копейки. Ну, там если app_id порядка 200 разных -- то было бы, допустим, в среднем 6000 записей. А у вас, видимо, нужный app_id был создан сильно не сначала -- и оказывается, что он берёт первые несколько лет, чтобы найти нужный. И у этой проблемы пока что нет решэния на уровне планировщика -- поскольку объяснить ему, что колонки коррелируют и считать лимит уменьшэнием во столько раз нельзя -- пока не получается.
Обсуждают сегодня