Комментарии 5
протупил. удалил комментарий самостоятельно.
Поправил ссылку коллектор метрик для Prometheus на https://github.com/prometheus-community/postgres_exporter
Всем хорошего дня. Автору отдельное спасибо.
В MS при просмотре плана запроса можно предположительно понять почему планировщик выбрал неоптимальный план, например по таймауту.
В Postgres 13 можно это так же посмотреть?
В MS при просмотре плана запроса можно предположительно понять почему планировщик выбрал неоптимальный план, например по таймауту.
в постгресе планировщик работает немного иначе, вместо таймаута для сложных запросов изначально выбирается другой алгоритм
В некоторых ситуациях рассмотрение всех возможных вариантов выполнения запросов занимает слишком много времени и памяти. В частности, это имеет место при выполнении запросов с большим количеством операций соединения. Поэтому, чтобы выбрать разумный (но не обязательно наилучший) план запроса за приемлемое время, PostgreSQL использует генетический оптимизатор запросов (см. Главу 60), когда количество соединений превышает некоторый предел (см. geqo_threshold).
Спасибо, почитаю. А в плане запроса это как то отразится?
Поясню почему возник вопрос. Есть кейс, в нем PostgreSQL вроде бы знал, что временная таблица не маленькая analyze на ней выполнен прямо перед запросом, на миллион строк, но пошел ее соединять вложенными циклами.
Какой у него критерий выбора разумного плана, вот это интересно посмотреть.
Что нового в плане мониторинга в PostgreSQL (Алексей Лесовский)