title

text

Леонид Борчук
Леонид Борчук Яндекс Разработчик
15:00 09 апреля
40 мин

Greenplum: командный центр вместо pg_stat_statements

В greenplum используется отличный от PostgreSQL подход для сбора статистики выполнения запросов: вместо pg_stat_statements - командный центр. Командный центр - отдельное приложение. А значит нет необходимости хранить статистику в разделяемой памяти. Но нужно отправлять ее отдельному процессу. Расскажу: - как мы его реализовали; - почему использование grpc в postgreSQL - плохая идея и с какими еще проблемами мы столкнулись; - какие хуки было бы неплохо добавить в postgreSQL; - как не тормозить на отправке данных; - какие новые возможности появляются у отдельного приложения.

Слайды

Слайды доступны участникам мероприятия, выполнившим вход в личный кабинет.

Видео

Видео доступно участникам мероприятия, выполнившим вход в личный кабинет

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

  • Евгений Пажитнов
    Евгений Пажитнов Postgres Professional TAM
    20 мин

    PgRAP: Программа оценки здоровья и рисков PostgreSQL

    Переход от реактивной поддержки СУБД к проактивной. У себя в компании Постгрес Про мы обрабатываем информацию по всем критическим инцидентам, докапываясь до корневых причин инцидентов. Причину каждого инцидента мы классифицируем по трём направлениям: Технологии, Люди и Процессы. Доклад описывает наш опыт в части комплексного подхода к предотвращению сбоев СУБД.

  • Владлен Пополитов
    Владлен Пополитов Postgres Professional разработчик программного обеспечения
    40 мин

    Зачем мне векторная база данных, если уже есть PostgreSQL?

    В 2023 году было анонсировано рекордное количество новых векторных баз данных. Mы расскажем о феномене векторных баз данных, раскроем суть этого явления и продемонстрируем, как векторные СУБД решают проблему производительности операций с векторами больших размерностей, и что препятствует реляционным базам данных конкурировать с ними в настоящее время. Несмотря на общий интерес к векторным базам данных, есть мнение о том, что существующие реляционные СУБД скоро смогут эффективно поддерживать операции с многомерными векторами, сохраняя традиционно богатый функциональный набор, что особенно важно для корпоративных пользователей. Например, для PostgreSQL уже созданы несколько расширений для работы с многомерными векторами, таких как pgvector, diskann, а также несколько коммерческих вендоров PostgreSQL объявили о поддержке работы с векторами. Мы рассмотрим используемые в этих расширениях алгоритмы, остановимся на недостатках и покажем возможные пути их улучшения.

  • П
    Павел Баев ФОРС-Центр разработки Инженер
    Андрей Пауков
    Андрей Пауков ООО «ФОРС – Центр разработки» Ведущий инженер
    Денис Леонтьев
    Денис Леонтьев ФОРС-Центр разработки ведущий инженер
    40 мин

    Диагностика производительности базы данных PostgreSQL / Diagnostics of PostgreSQL database performance

    ЦТП ФОРС имеет более чем 30 летний опыт поддержки промышленных СУБД на основе Oracle, последние 9 лет мы оказываем услуги по PostgreSQL. Накопленную за много лет методику применяем в нашей работе. В докладе делаем обзор с примерами использования штатного инструментария диагностики производительности СУБД и ОС. Представляем собственный инструмент PGARM, и как он помогает нам вести диагностику замедлений, в том числе в реальном времени.


    FORS Center of Technical Support with over 30 years of experience in supporting Oracle-based RDBMS has been providing support services for PostgreSQL-based DBMS for the last 9 years. We leveraged our extensive experience gained over many years while developing our PGARM tool. In the presentation we provide a comparison between standard tools for diagnosing DBMS and OS performance and our PGARM. Today we would like to present our own tool: PGARM and to demonstrate how it can help you diagnose slowdowns, including real time diagnostics.

  • А
    Андрей Лепихов
    Алена Рыбакина
    Алена Рыбакина Postgres Professional Разработчик
    40 мин

    Перепланирование безнадежных запросов в реальном времени

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