Как PostgreSQL может сделать больно, когда не ожидаешь?
Тезисы
Время выполнения SQL-запросов зависит от наличия индексов, актуальной статистики и т.п. Большинство проблем с производительностью СУБД решаются оптимизацией самых медленных запросов. Но, увы, бывают ситуации, когда классическая оптимизация запросов не приносит желаемого успеха. Система продолжает себя вести неадекватно.

На примере нескольких ярких инцидентов поделюсь опытом исследования проблем с производительностью в PostgreSQL:
  • Почему index scan / index only scan могут тормозить при адекватном плане запроса?
  • Почему индексы вообще могут не использоваться?
  • Почему может блокироваться таблица, если код приложения этого не делал?
  • Как время между приложением и базой может стать критическим фактором для производительности системы?
Время выполнения SQL-запросов зависит от наличия индексов, актуальной статистики и т.п. Большинство проблем с производительностью СУБД решаются оптимизацией самых медленных запросов. Но, увы, бывают ситуации, когда классическая оптимизация запросов не приносит желаемого успеха. Система продолжает себя вести неадекватно.

На примере нескольких ярких инцидентов поделюсь опытом исследования проблем с производительностью в PostgreSQL:
  • Почему index scan / index only scan могут тормозить при адекватном плане запроса?
  • Почему индексы вообще могут не использоваться?
  • Почему может блокироваться таблица, если код приложения этого не делал?
  • Как время между приложением и базой может стать критическим фактором для производительности системы?
Видеозапись доклада
Появится здесь после конференции
Информация о спикере
Михаил Жилин
Руководитель команды производительности, Postgres Professional
  • Михаил Жилин
    Руководитель команды производительности, Postgres Professional
Все доклады трека