Как работает оптимизатор PostgreSQL при большом количестве таблиц в запросе

[akhkmed]

Спасибо за статью. Зачастую сталкивался, что большое число партиций сильно влияет на план выполнения. Они также плюсуются до join_collapse_limit ?

Что касается управления порядком join предположу, что join в подзапросах наверняка выполняются первыми. Но CTE уж точно, особенно materialized.

Кстати, если делать join с партицированными таблицами, часть из которых fdw, то план также сильно меняется. Настройки use_remote_estimate, fdw_tuple_cost и fdw_startup_cost, безусловно, работают, но восстановить адекватный план не всегда возможно.

[ptolmachev]

Здравствуйте.

"Зачастую сталкивался, что большое число партиций сильно влияет на план выполнения. Они также плюсуются до join_collapse_limit ?"

Спасибо за интересный вопрос. Я пока точного ответа не знаю, возможно что действительно плюсуются до join_collapse_limit. Но лучше протестировать, проверить руками. Это интересная тема для будущих исследований :)

По теме секционирования Павел Лузанов хорошую статью написал "Не очень большие данные", там в т.ч. про параметр enable_partitionwise_join рассказано. Может быть, в вашем случае можно его попробовать использовать.

Материализация CTE - это, действительно, способ повлиять на план. Подробнее про материализацию CTE можно прочитать в статье Игоря Левшина "Игра в прятки с оптимизатором. Гейм овер, это CTE PostgreSQL 12".

[markhor]

Я в прошлом году начал использовать pg_hint_plan и не могу нарадоваться: больше никаких причуд планировщика. Обнаружил что в большинстве случаев фейлы происходят из-за неправильного предсказания числа записей (у меня до сотен тысяч возвращается) и хинты Rows отлично их исправляют. Подробнее в моей статье.

[ptolmachev]

Здравствуйте. Да, использование pg_hint_plan - это тоже способ работы.

Кстати, вашу статью (перевод) я сначала на хабре прочитал, а потом уже оригинал.