Коллеги, не сталкивались с PG с ситуацией, когда analyze, на

большой таблице (50млн строк) ломает план запроса?
Т.е. делаешь реиндекс - все ок, обновляешь статистику по таблице - все плохо.

Не подскажите откуда скрин?

Это тензора сервис. Пользуюсь несколькими: https://explain.tensor.ru https://explain.dalibo.com https://explain.depesz.com

Благодарю

Запрос вроде небольшой - скиньте планы текстом, а то на скринах не все видно...

https://pastebin.pl/view/b3b773fa

Большое количество строк. Планировщик принимает решение обходить все строки ввиду большого их количества. Есть настройки в conf постгреса . Но строк много планировщик будет игнорить индексы.

Заменил ссылку, добавил еще план запроса по быстрому варианту после реиндекса

Как тогда понимать, когда делаешь реиндекс, т.е. ПГ пересоздал индексы и сделал аналайз+статистику и план дает быстрый, но делаешь ручной аналайз и в план прилетает лишний NL? Запрет NL проблему конкретно этого плана решает, на сама база начнет работать в других запросах медленней.

Так можно nl запретить только на этот запрос. Хотя это плохой вариант, конечно.

Кстати, а нет ли чего странного с табоицэй _inforg23326 ? Лежыт на hdd? Активно обновляется в процэссе запроса? Давно не реиндэксировалась? Реально селективность индэкса _inforg23326_1 невелика, тысячи записей с одинаковыми остальными полями индэкча и _fld23332=true ? Там какое-то ненормальное кмк время доступа к ней в случае nested loop.

Ну и, хорошо бы посмотреть что после analyze так меняется в оцэнках. Там видно, что правильный план даёт cost миллион, неправильный — два милииона. Значит, что-то случилось с оцэнкой правильного, что она подросла, кроме прочего. Хотя, конечно, оцэнка в два миллиона на 900 секунд — тожэ выглядит ошыбкой.