Привет.
имеем вот такой простой запрос



видно что планировщик сильно промазал в оценке кол-ва строк. Далее








Почти точно.

в таблице datas 56k строк
в таблице types 15 строк с уникальными "name"
Понятно, что в случае с подзапросом, он разделил 56000/15 и получил среднее ожидаемое 3758 строк, но можно ли как то заставить высчитать реальное значение?
Пробовал limit ставить, уник. индекс строить...не помогает.

Alexiusgav21,

можно в stable хранимку подзапрос засунуть, чтобы заставить вычислить подставляемое значение typeid на этапе планирования.
либо оптимизировать проблемный запрос другими способами (не обязательно вправляя оценку строк в этом месте).

Спасибо за совет.
Проблема решилась иначе.
Если коротко - был запрос с 11 подзапросами во FROM, и оптимизатор строил план на nested loop с такими вот промахами в оценках. Если через set запрещать nested loop, то на hash join все работало хорошо.
Позже я вспомнил про параметр from_collapse_limit, увеличение которого чудесным образом вправило мозги оптимизатору и план стал вменяемый.