записей) следующего вида:
explain (ANALYZE, BUFFERS) SELECT ......
FROM .... Набор джойнов по справочникам...
WHERE ... Фильтры по справочникам...
ORDER BY shema.task.deadline_time, shema.task.created_at
LIMIT 30
Проблема в том, что запрос отрабатывает 3 секунды и очень дорого стоит.
Специально для запроса создан двойной индекс по полям, которым идёт сортировка
CREATE INDEX deadline_time_created_at_idx ON shema.task USING btree (deadline_time, created_at)
Но планировщик строит запрос какими-то окольными путями. При этом если добавить к сортировке дески:
ORDER BY
shema.task.deadline_time DESC, shema.task.created_at DESC
То запрос начинает отрабатывать как надо за 2-3 миллисекунды пробегая по индексу (!причём в обратном порядке! Тк по умолчанию индекс создан asc) ~ 400 строк и набирая по условиям первые встретившиеся необходимые 30 полей.
А если DESC из ордер бай убрать, то индекс задействуется в каком-то там фулл скане и работа идёт со всей таблой попавшей под условия и там вообще страх и ужас я даже не вникал глубоко. Хотя по идее тут даже не обратное а прямое сканирование первых удовлетворяющих условиям строк должно быть. Есть идеи, почему такой парадокс?
Скорее всего у вас where по этим же ролям, и оно сочетается с desc, но не с asc
По полям, которым сортируется запрос, нету ни условий ни джойнов. Нигде кроме сортировки они не всплывают. Ну только в самой выборке экземпляра уже
Попробуйте для таблиц увеличить объём собираемой статистики
Попробуйте выборку увеличить временно, сделать аналайз и посмотреть план
Спасибо, завтра попробую. Но вообще по идее если он совсем наглухо не выключен, то не должно быть такого. Проблемный запрос существует уже давно, явно были аналайзы за это время. А структура наполнения таблицы принципиально не менялась
Да понятно, и на order by не должно конечно влиять, просто для больших таблиц значение целевых строк статистики достаточно маленькое
Докидываю фактуру. Запросы, планы и версия в txt Полную выгрузку по всем таблицам прислать к сожалению не могу. Сделал выгрузку по столбцам сортировки в файлике -d @tzirechnoy
Честно говоря уже раз 7 перечитал, но не пойму. Объясните пожалуйста. - сортировка по индексу ведь необходима? В случае деск он не читает всю таблицу, потому что уверен что индекс отсортирован, и начиная с его конца, он берёт самые крайние значения Дедлайн+креатед? -почему моё понимание сортировки обратно реальному?
А про понимание сортировки индэкса — потому, что в индэксе на дату, отсортированном по asc, в начале будут самые ранние значения, а не самые последние. Но тут это вообще неважно — хоть так хоть так, скорость заметно не изменится.
Обсуждают сегодня