Postgres Query Plan продолжает меняться - делает запрос в минуту, чтобы иногда заканчивать и никогда не заканчивается иногда

Question

У меня огромный SQL-запрос. Вероятно, это было 15-20 таблиц. Есть 6-7 подзапросов, которые снова соединяются. Этот запрос в большинстве случаев занимает минуту, чтобы запустить и вернуть 5 миллионов записей.

Так что даже если этот запрос плохо написан, у него есть план запросов, который заставляет его закончить через минуту. Я гарантировал, что запрос действительно выполнялся и не использовал кешированные результаты.

Иногда план запроса поднимается, а затем он не заканчивается. Каждый вечер я запускаю вакуумный анализ на таблицах, участвующих в запросе. В настоящее время work_memory установлен на 200 МБ. Я попытался увеличить это до 2 ГБ. Я не испытал, что запрос запутался, когда work_memory составлял 2 ГБ. Но когда я уменьшил его и запустил запрос, он запутался. Теперь, когда я увеличил его до 2 ГБ, запрос все еще запутан. Это что-то связано с тем, что план запроса не обновляется с новой настройкой? Я попытался отказаться от плана на моей сессии.

Я могу только думать о work_mem и анализе вакуума на этом этапе. Любые другие факторы, которые могут повлиять на плавно выполняемый запрос, который возвращает результаты за минуту, чтобы пойти и ничего не вернуть?

Дайте мне знать, если вам нужна дополнительная информация о любых настройках? или сам запрос? Я также могу вставить план тоже ... Но запрос и план или слишком большой, чтобы вставлять здесь.

Answer 1

Если в таблице диапазонов содержится более geqo_treshold (обычно 12) записей, генетический оптимизатор будет пинать , часто приводящее к случайным поведением, как описано в вопросе. Вы можете решить эту проблему:

• увеличивающейся geqo_limit
• переместить некоторые из табличного referencess в КТР. Если у вас уже есть некоторые подзапросы, продвиньте один (или более) из них в CTE. Это своего рода черное искусство для определения кластеров таблиц в вашем запросе, которые будут соответствовать компактному CTE (с относительно небольшим количеством исходных кортежей и не слишком много ключевых ссылок на внешний запрос).

Установка geqo_treshold слишком высокая (20, вероятно, слишком высокая ...) заставит планировщика потребоваться много времени, чтобы оценить все планы. (количество планов увеличивается в основном экспоненциально по количеству RTE). Если вы ожидаете вашего запроса, чтобы потребоваться несколько минут для запуска, несколько секунд времени планирования, вероятно, не повредят.