PGConf.Russia 2018

"Не мог он GIN от SP-GiST-а, как мы ни бились, отличить", говорил классик. А вы можете? Этот мастер-класс посвящен индексам, которые хоть и не так часто используются, как обычное B-дерево, но могут сильно выручить в трудную минуту. Мы посмотрим, как устроены эти индексы и в каких случаях они могут быть успешно применены. Заодно поговорим и об особенностях индексного доступа в PostgreSQL. Чтобы провести время с пользой, от слушателей потребуется некоторое знакомство с PostgreSQL и умение читать планы несложных запросов.

Материалы мастер-класса

• Слайды
• Demo 1
• Demo 2
• Demo 3

Резервную копию БД с демонстрационными данными можно скачать тут:

• Восстановление с помощью pg_restore (338 MB)

В 10-й версии постгреса появилось встроенное партицирование таблиц. Однако ставить точку на развитии этого функционала, начало работы над которым ведётся с августа 2015 года, пока рано. В новом 11-ом релизе ведутся несколько параллельных работ по преодолению ограничений встроенного партицирования (update ключа партицирования, вставка в foreign партиции, локальные и глобальные индексы) и внедрение оптимизаций (runtime partition pruning, parallel append нода и partition-wise aggregation/grouping), которые восполнят многолетний пробел в этой области.

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

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

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

• Большие накладные расходы на распаковку записей.
• Затраты на интерпретацию запроса (Постгрес интерпретирует план выполнения запроса)
• Поддержка работы с абстрактными типами
• Недостатки PULL модели выполнения запроса
• Издержки MVCC

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

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

На текущий момент работа над подключаемыми хранилищами перешла в практическую плоскость: ведётся тред, в котором несколько человек разрабатывают набор патчей, и ещё больше делают ревью.

В данном докладе будут рассмотрены следующие вопросы:

• обзор получившегося интерфейса для подключаемых хранилищ;
• изменения в ядре PostgreSQL, которые потребовались для реализации данного интерфейса;
• текущие и потенциальные применения данного интерфейса, включая heap с undo-логом и in-memory OLTP движок;
• текущее состояние патчей и перспектива их принятия в ядро;
• дальнейшее развитие интерфейса с целю расширения возможностей подключаемых хранилищ (columnar, index-organized, LSM и т.д.).