![Екатерина Соколова Екатерина Соколова](/media/2021/10/05/проф.jpeg.180x180.jpg)
Дело о пропавшей производительности в PostgreSQL: руководство по поимке и обезвреживанию проблемных запросов
Город спит, даже не догадываясь, как мужественно администраторы баз данных ради всеобщего блага сражаются за ускорение выполнения запросов на даже долю секунды. Используем встроенные инструменты PostgreSQL, чтобы • вычислять неоптимальные запросы, • избегать проблем с ними в будущем • и даже принимать решения на ходу, без остановки их выполнения.
Другие доклады
-
Владимир Бурба ООО Сигма Начальник управления разработки и тестирования
Использование JSONB полей вместо EAV в PostgreSQL
Успешный кейс использования JSONB полей, как основных для хранения всей бизнес информации в высоконагруженной CRM системе.
-
Василий Пучков ООО «ЛУКОЙЛ-Технологии» Главный эксперт
Как мы тестировали Postgres Pro BiHA
"Сад разложенных граблей" или что мы хотели получить;
"Сделать хотел сеппуку, а вышло опять харакири" или что мы получили;
"Я изоленту принёс" или как нам жить дальше. -
Дарья Лепихова Postgres Professional разработчик ПОААлексей Дарвин Postgres Professional менеджер продукта
-
Алена Рыбакина Postgres Professional разработчик
Адаптивный исполнитель запросов
К сожалению, уже давно известны случаи, когда оптимизатор строит неоптимальный план запрос, и часто данные случаи связаны с неверной оценкой кардинальности - из-за ожидания малого количества данных, оптимизатор предпочитает выбрать NestedLoop вместо других соединений, из-за чего время выполнения запроса может растянуться по времени. Наша команда разработала расширение SwitchJoin, которое имеет возможность, помимо основного выбранного оптимизатором пути NestedLoop, сформировать запасной, и, в случае, если количество кортежей было предсказано слишком малое, может переключаться на него.