PgConf.Russia 2019

В конце прошлого года мне поступил заказ на доработку расширения ltree с более полным набором символов. Доклад рассказывает о

• изначальном состоянии расширения
• расширенном синтаксисе
• процессе доработки и тестирования расширения.

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

Для того, чтобы решить эту проблему, я разработал инструмент под названием pg_plan_advsr - это расширение для PostgreSQL, которое исправляет ошибки оценки путем неоднократного возвращения в планировщик информации, собранной в ходе исполнения запроса.

Расширение содержит три фичи:

1. Автоматическая оптимизация плана запроса за счет неоднократного возвращения информации о ходе выполнения запроса в планировщик.
2. Сохранение всех выработанных при оптимизации планов запросов в таблицу истории.
3. Создание и сохранение хинтов оптимизатора с тем, чтобы иметь возможность воспроизвести выработанные планы исполнения запросов в процессе настройки.

Я верифицировал эффективность pg_plan_advsr путем запуска join order benchmark (JOB) на PG 10.4, в ходе чего наблюдалось сокращение времени исполнения запроса до 50% от первоначального. Таким образом, расширение будет полезно пользователям, который хотят настроить планировщик для OLAP и пакетной обработки данных.

В ходе презентации я расскажу о следующие моментах:

• Принципы построения и архитектура pg_plan_advsr.
• Подробная информация о результатах тестирования JOB.
• Направления улучшений в будущем.
• Совместное использование расширений aqo и pg_plan_advsr together (экспериментальное).

СУБД внутри контейнера - ночной кошмар для администратора баз данных. Я расскажу, как PostgreSQL в контейнерах используется в Juno, с какими сложностями мы столкнулись и как их преодолели.

Многие специалисты, обслуживающие СУБД не любят эти три буквы - ORM, потому что не раз видели сгенерированные многоэтажные запросы для простейших операций. Однако, практика показывает, что источник проблемы - не ORM, а разработчики, не умеющие ими пользоваться. В этом докладе я расскажу основные принципы, как писать код для ORM, генерирующий «хорошие» запросы, а также покажу «плохие» примеры кода, и что из них получается на выходе. Основные идеи – при написании кода мыслить в SQL, научиться заранее видеть, какой запрос будет сгенерирован. Но даже обретя такой навык нужно всегда проверять выходной SQL для сложных запросов. Приведу конкретный пример, когда незначительное изменение в ORM-логике меняет объём выходного SQL в десятки(!) раз. Расскажу о дополнительных инструментах и хитростях. А именно – отключение трекинга, конструкция Include, разный синтаксис для JOIN, как получить больше данных за меньшее число запросов, как эффективно писать запросы с группировкой, и зачем нужны проекции. Не обойду стороной и случаи, когда эффективно решить задачу средствами ORM не получается (например, запросы с рекурсией). Кроме SELECT-запросов немного расскажу о средствах Batch-Update/Delete, позволяющих обновлять и удалять данные средствами ORM без загрузки на клиент. Несколько слов будет и о вставке – как заставить ORM быстро вставлять большие объёмы данных через Multi-Insert и COPY. Будет упомянуто и о поддержке в ORM специфичных для PostgreSQL типов данных – массивов, hstore и jsonb. Может возникнуть вопрос – а есть ли вообще смысл использовать ORM, раз нужно столькому научиться. Преимущества их использования есть, и об этом тоже будет сказано. Все примеры будут на технологии Entity Framework для платформ .Net Core и .Net Framework на языке C#. Для Hibernate/NHibernate могут быть отличия в некоторых тонкостях, но основные принципы те же, поэтому доклад будет полезен разработчикам, использующим различные технологии.