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