title

text

Михаил Цветков
Михаил Цветков Intel Технический директор
: декабря
45 мин

Технологии Intel для PostgreSQL

Расскажем о продуктах и решениях Intel для сегмента Data Platform Group: серверных процессорах Xeon 3rd Gen (4S Cooper Lake), памяти PMEm 200 Series, и FPGA.

Видео

Другие доклады

  • Андрей Лепихов
    Андрей Лепихов Postgres Professional Программист
    22 мин

    Постгрессовый планнер с памятью

    Постгрес умеет строить оптимальные планы запросов для большинства практических случаев. Однако иногда, по объективным причинам, для сложных запросов или из-за ошибок в самом планнере, он может ошибаться и выдавать неоптимальный план. Из-за этого, время выполнения такого запроса может возрастать в десятки раз. Если запрос выполняется часто, то из раза в раз этот запрос выполняется дольше, чем мог бы, и СУБД в целом выдает меньший TPS. Если планнер сможет фиксировать свои ошибки и учитывать их при последующем планировании того же запроса, то это позволит улучшать характеристики СУБД в процессе её эксплуатациии. Мы представляем результаты разработки расширения для СУБД PostgreSQL, которое хранит историю выполнения запросов и реализует рекомендательный механизм для планнера. Показываем, как знание о ранее выполнявшихся запросах позволяет улучшить выполнение последующих.

  • Julien Rouhaud
    Julien Rouhaud Разработчик
    Tatsuro Yamada
    Tatsuro Yamada NTT Comware Ведущий специалист по базам данных
    22 мин

    Построение автоматического консультанта и инструментов настройки производительности в PostgreSQL

    PostgreSQL - зрелая реляционная СУБД, её история насчитывает более 30 лет. За последний год её оптимизатор запросов стал лучше, и обычно он создаёт хорошие планы выполнения запросов.

    Но всегда ли эти планы выполнения запросов хороши? Чтобы оптимизировать процесс их создания, приходится пользоваться предположениями, чтобы планы выполнения запросов создавались достаточно быстро. Некоторые из этих предположений проверить довольно легко (например, актуальность статистики), другие сложнее (например, надо убедиться, что правильные индексы были созданы), а некоторые проверить почти невозможно (например, убедиться, что выборки достаточно репрезентативны даже для ассиметричного повторного секционирования данных). Сегодня из-за всех этих предположений администратор базы данных не всегда осознаёт, что он мог бы добиться значительного улучшения производительности.

    Чтобы помочь администраторам баз данных работать с действительно хорошим планом выполнения запросов, ниже мы представим несколько инструментов, которые могли бы помочь решить вышеупомянутые проблемы. Мы расскажем о консультанте для недостающих индексов, поиске недостающей статистики для создания новых метрик, а также информации для исправления ошибок в оценке строк (при этом порядок выполняемых операций соединения и оператор соединения определяются автоматически).

    • pg_qualstats предоставляет подсказки для создания новых индексов и расширенной статистики чтобы собрать много предикатных статистических данных о производственной нагрузке.
    • pg_plan_advsr создаёт альтернативные планы выполнения запросов автоматически для анализа информации об итеративном выполнении запросов, чтобы исправить ошибку оценки строк.

    В рамках этого доклада мы объясним, как устроены эти инструменты, что можно делать с их помощью, и как эффективно использовать оба инструмента вместе. Мы также упомянем другие инструменты для решения смежных проблем. Поэтому наш доклад будет полезен администраторам баз данных, которые заинтересованы в улучшении производительности при выполнении запросов или хотят проверить адекватность существующих настроек, индексов или статистики.

  • Алексей Лесовский
    Алексей Лесовский Data Egret PostgreSQL DBA
    22 мин

    Noisia - генератор аварийных и нештатных ситуаций в PostgreSQL

    Noisia это результат всех предыдущих попыток собрать в одном месте все мои инструменты для воспроизведения нештатных и аварийных ситуаций в Postgres.

    Noisia это утилита которая позволяет легко и непринужденно создавать аварийные ситуации в БД. В этом докладе я расскажу зачем потребовалось создавать такие ситуации, как теперь в этом помогает Noisia и где еще может пригодиться этот инструмент. Также хочу поделиться планами развития на будущее.

  • Christopher Travers
    Christopher Travers DeliveryHero SE Principle Engineer
    45 мин

    Когда всё идёт не так: как надо и как не стоит реагировать на инциденты при поддержке СУБД

    Однажды в Adjust мы столкнулись с проблемой скорого достижения предельного значения xid в очень централизованной базе данных из-за длительной остановки autovacuum. Поскольку мы заметили предупреждения за 5 часов до надвигающейся катастрофы, мы смогли минимизировать влияние проблемы на клиентов. Приходите на доклад, чтобы узнать, как мы использовали это время для подготовки и какие уроки это может преподать всем, кто сталкивается с необычными проблемами в больших базах данных.