Адаптивный исполнитель запросов
К сожалению, уже давно известны случаи, когда оптимизатор строит неоптимальный план запрос, и часто данные случаи связаны с неверной оценкой кардинальности - из-за ожидания малого количества данных, оптимизатор предпочитает выбрать NestedLoop вместо других соединений, из-за чего время выполнения запроса может растянуться по времени. Наша команда разработала расширение SwitchJoin, которое имеет возможность, помимо основного выбранного оптимизатором пути NestedLoop, сформировать запасной, и, в случае, если количество кортежей было предсказано слишком малое, может переключаться на него.
Другие доклады
-
40 мин
.jpg.180x180.jpg "Владимир Бурба")
Владимир Бурба ООО Сигма Начальник управления разработки и тестированияИспользование JSONB полей вместо EAV в PostgreSQL
Успешный кейс использования JSONB полей, как основных для хранения всей бизнес информации в высоконагруженной CRM системе.
-
40 мин
Екатерина Соколова Postgres Professional РазработчикДело о пропавшей производительности в PostgreSQL: руководство по поимке и обезвреживанию проблемных запросов
Город спит, даже не догадываясь, как мужественно администраторы баз данных ради всеобщего блага сражаются за ускорение выполнения запросов на даже долю секунды. Используем встроенные инструменты PostgreSQL, чтобы • вычислять неоптимальные запросы, • избегать проблем с ними в будущем • и даже принимать решения на ходу, без остановки их выполнения.
-
40 мин
Игорь Сидельников Иннотех Старший бизнес-экспертWatchDog: применение Prophet и Scikit-learn (SKLearn) в прогнозировании роста объёмов баз данных PostgreSQL.
В докладе, осветим актуальность темы прогнозирования роста баз данных PostgreSQL. Коснёмся факторов, которые влияют на рост баз данных PostgreSQL. Сравним Prophet и Scikit-learn - для решения задачи прогнозирования роста БД. Подробно расскажем о шагах, реализованных в WatchDog, по решению этой задачи, и - полученных результатах.
-
40 мин
Александр Котин Postgres Professional TPMИнструменты Postgres Pro для исправления, фиксации и миграции планов проблемных запросов.
Для большинства клиентских приложений существует ряд ключевых запросов, время выполнения которых не может превышать критических значений. Но из-за отставания статистик или иных причин, оптимизатор Postgres часто не может найти оптимальный план, что приводит к недопустимым задержкам. А так как запросы создаются автоматически, то исправить их со стороны клиентского приложения сложно или невозможно. В докладе расскажем о том, как можно решать такие проблемы со стороны СУБД. Покажем, как с помощью набора инструментов Postgres Pro идентифицировать такие запросы, исправлять и фиксировать планы, переносить их на реплики в автоматическом режиме, а также как осуществить перенос планов при апгрейде с 15й версии.