Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Релизы

Как и обещано, бета-версия PostgreSQL 11 вышла 25-го мая. Ее новшества по отношению к 10.х в основном уже перечислены в сводке Что заморозили на feature freeze.

Postgres Pro 10.4.1
Компания Postgres Professional выпустила новые релизы Postgres Pro Standard/Enterprise 10.4.1, созданные на базе PostgreSQL 10.4 и Postgres Pro 10.3.2. В них вошли все улучшения версии PostgreSQL 10.4, а также ряд важных доработок:

• обновлён модуль jsquery, отвечающий за запросы к типу данных jsonb;
• утилита pg_probackup для управления резервным копированием и восстановлением кластеров баз данных обновлена до версии 2.0.17 и дополнена новыми возможностями; например, добавлен режим DELTA, в котором считываются все файлы данных в каталоге и создаётся инкрементальная копия для страниц, изменённых со времени предыдущего копирования;
• модуль pg_pathman, отвечающий за секционирование больших и распределённых баз данных, обновлён до версии 1.4.11, в которой исправлен ряд ошибок;
• исправлена сортировка букв «Ё» и «Й» в модуле mchar, предоставляющем дополнительные типы данных для совместимости с Ms SQL Server;
• доработана версия для Windows.

На прошлой неделе, с 29 мая по 1 июня, состоялась конференция PGCon 2018. PGCon проходит в Оттаве каждый год. В отличие от других конференций, посвященных PostgreSQL, PGCon позиционируется, как конференция не пользователей, а разработчиков. Это делает ее крайне важным событием в жизни проекта. Далее я хотел бы поделиться своими впечатлениями от конференции и рассказать о наиболее запомнившихся мне моментах.

Несколько недель перед важным комитфестом — последним перед feature freeze версии PostgreSQL 11 — читатели рассылки hackers, сжимая в левой пакет с чипсами, следили за триллером MERGE. Режиссер триллера, глава компании 2ndQuadrant Саймон Риггс (Simon Riggs), с впечатляющей настойчивостью и изобретательностью пытался протащить в версию патч, реализующий синтаксис команды MERGE. Риггс комитер с 2009 года, а со статусом комитера можно самому утверждать патчи. Ему противостояли не менее уважаемые комитеры и ветераны PostgreSQL. Страсти кипели явно и подспудно, до прямых оскорблений все же не дошло — факт удивительный для завсегдатаев многих отечественных форумов. Однако некоторое напряжение осталось до сих пор, когда вопрос утрясли, и спорить уже не о чем.

Представьте ситуацию. Субботний вечер. Вы — администратор PostgreSQL, после тяжелой трудовой недели уехали на дачу за 200 км от любимой работы и чувствуете себя прекрасно… Пока Ваш покой не нарушает смс от системы мониторинга Zabbix. Произошел сбой на сервере СУБД, база данных с текущего момента недоступна. На решение проблемы отводится короткое время. И Вам ничего не остается, как с тяжелым сердцем оседлать служебный гироскутер и мчаться на работу. Увы!


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

Как бы то ни было, стоит подумать о технологиях отказоустойчивы кластеров с СУБД PostgreSQL. Мы расскажем о построении отказоустойчивого кластера СУБД PostgreSQL с помощью программного обеспечения Pacemaker&Corosync.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Релизы

PostgreSQL 11 Beta
Релизная команда PostgreSQL определилась с датой выпуска бета-версии: 24 мая 2018.

Вышел PostgreSQL 10.4

В отличие от версии 10.3, которая была внеплановой (нужно было срочно закрыть важные дыры в безопасности), эта версия вышла в соответствии с графиком.
В новой версии много поправок. Из заплаток, привлекших внимание: излишне либеральный доступ (ACL) к функции pg_logfile_rotate(); ослаблены блокировки во время планирования фоновых процессов автовакуума, которые сильно мешали распараллельнию работы. Вместе с 10.4 вышли обновления 9.6.9, 9.5.13, 9.4.18, 9.3.23.

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

И теперь совместно с компанией «Райффайзенбанк», мигрировавшей на PostgreSQL ряд систем, мы решили провести открытый митап по новым фичам в PostgeSQL 11.

Ждем вас 23 мая в 18.00 в Нагатинском офисе Райффайзенбанка по адресу Москва, проспект Андропова 18, корпус 2.

Вход бесплатный. Регистрация на сайте.

Продолжая тему новый возможностей грядущего релиза PostgreSQL 11 (предыдущие посты: раз, два, три), я хотел бы рассказать об одном небольшом, но важном изменении. Изменение это касается кастинга одних типов в другие. И, конечно же, оно касается JSONB, потому что в PostgresPro мы его очень любим!

В предыдущих постах вы могли прочитать про INCLUDE-индексы и встроенный веб-поиск. Эти фичи появятся в PostgreSQL 11, релиз которого, напомню, планируется в октябре. Сегодня мне хотелось бы продолжить обзор новых фичей грядущего релиза, рассказав про JSONB-трансформы для языков PL/Python (3f44e3db) и PL/Perl (341e1661). Оба патча написаны Антоном Быковым.

Feature freeze

Это, конечно, главное событие для сообщества. То, что не прошло только что закончившийся комитфест, не попадет в версию PostgreSQL 11.

Что заморозили на feature freeze
Это наша сводка попавших в нее важнейших патчей.
Сводка сводкой, а статьи об PostgreSQL 11 уже начали появляться. А дальше — больше.

Waiting for PostgreSQL 11 – Transforms for jsonb to PL/Python and to PL/Perl
Депеш, то есть Хуберт 'depesz' Любашевски, пишет в своем блоге о 2 соответствующих патчах Антона Быкова из Postgres Professional.

Postgres 11 highlight — Covering Indexes
В своем блоге Мишель Пакье (Michael Paquier) пишет о покрывающих индексах (см также статью Что нового в PostgreSQL 11: INCLUDE-индексы Александра Алексеева из Postgres Professional и комментарии к ней). На эту же тему — INCLUDE-индексов — статья Waiting for PostgreSQL 11: Covering + unique indexes Алексея Лесковского из Data Egret.

Partition Elimination in PostgreSQL 11
По поводу этого серьезного достижения 11-й версии пишет в своей статье Дэвид Роули (David Rowley) из 2ndQuadrant.

Об еще одном патче, прошедшем в PostgreSQL 11, пишет в статье Что нового в PostgreSQL 11: встроенный веб-поиск тот же Александр Алексеев.

Manipulating checksums of a cluster
Мишель Пакье пишет еще об одном патче PostgreSQL 11. Патч проверяет чексуммы страниц после штатной остановки кластера. Более того, он предлагает свою утилиту pg_checksums на базе этого патча.

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

8-го апреля закончился комитфест 2018-03. Те патчи, которые не закомичены на нем (и на 3 предыдущих комитфестах) уже не попадут в релиз PostgreSQL 11: произошла заморозка функциональности (feature freeze). Время подводить итоги.

Главные новости последнего комитфеста (и версии 11 соответственно):

• увесистый набор патчей для секционирования.
• JIT-компиляции посвящен только один патч, но это шаг в направлении, которое в будущем наверняка будет развиваться интенсивно.
• «покрывающие» индексы (INCLUDE-индексы). Это тема уже активно обсуждается и продолжается в разработках.
• Серия патчей в группе процедурных языков. Они важны в том числе для совместимости со стандартами SQL и миграции с Oracle.
• Интересные, но не столь резонансные патчи.

Начнем в произвольном порядке.

У многих достижений версии PostgreSQL 10 прописка в разделе Секционирование (Partitioning). И это справедливо: очевидно, что при переходе от 9.6 к 10 произошел мощный технологический скачок. В предыдущих версиях секции строили и управляли ими, теми средствами, что уже имелись: механизмом наследования со всеми его ограничениями и неудобствами.

В версии 10 перешли к более специализированным механизмам и более привычному (в том числе для пользователей Oracle, а с этим приходится считаться) синтаксису. Этот скачок при переходе от 10 к версии 11 должен был подкрепиться важными дополнениями, которые должны расширить функциональность и улучшить производительность операций, использующих секционирование. Но из итогов последнего комитфеста (он закончился 8 апреля) видно, что не все задуманное удалось довести до рабочего состояния, а значит не все попадет в версию 11.

К тому же последние пару лет параллельно велись разработки модуля pg_pathman в Postgres Professional. Некоторые важные возможности пересеклись, некоторые остались уникальны для PostgreSQL и pg_pathman (который работает с ванильной версией, то есть PostgreSQL 10 + pg_pathman дает уже вполне впечатляющую сумму функциональности). Об этом будет отдельная статья. Замечания, относящиеся к версии 11 и к pg_pathman для удобства выделены курсивом.

Эта статья представляет собой переработанные и дополненные фрагменты книжки Nouveaulités de PostgreSQL 10. (с) Dalibo, перевод с французского Игоря Лёвшина (оригинал). Примеры из книги проверены, иногда адаптированы и локализованы для большей наглядности.

Релиз PostgreSQL 11 состоится еще не скоро, только в октябре. Но фичфриз уже наступил, а значит мы знаем, какие фичи попали в этот релиз, и можем их потестировать, собрав PostgreSQL из ветки master. Особого внимания заслуживает фича под названием INCLUDE-индексы. Патч изначально написан Анастасией Лубенниковой, а потом допилен Александром Коротковым и Федором Сигаевым. Протолкнуть его в PostgreSQL заняло «всего лишь» что-то около трех лет.

(В статье использованы примеры и пояснения из книги Nouveaulités de PostgreSQL 10. (с) Dalibo, перевод с французского Игоря Лёвшина, редактор Егор Рогов (оригинал). Примеры проверены, иногда изменены для большей наглядности)

Конечно, мы уже ждем не дождемся появления 11-й версии PostgreSQL. Но уже сейчас ясно, что некоторые довольно радикальные улучшения производительности появились уже в версии 10. Определенно есть смысл разобраться сначала с ними.

Производительность "десятки" улучшилась сразу в нескольких направлениях. В этой статье речь пойдет об ускорении за счет:

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

Мы начнем с параллелизма.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Релизы

Вышел PostgreSQL 10.3

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

Версия Postgres Pro Standard 10.3.1 вышла в тот же день, что и PostgreSQL 10.3, так как необходимо было залатать дыру как можно быстрее. Сейчас доступны уже Postgres Pro Standard 10.3.2 и Postgres Pro Enterprise 10.3.2. В них в том числе добавлена поддержка TOAST для атрибутов INCLUDED в индексах-B-деревьях. Серьезно усовершенствована утилита pg_probackup (теперь это версия 2.0.16).

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

Надо признать, что собственные агрегатные и оконные функции встречается довольно редко. Оконные функции вообще по каким-то причинам традиционно относят к разряду «продвинутого» SQL и считают сложными для понимания и освоения. Тут бы разобраться с теми функциями, которые уже имеются в СУБД!

Зачем тогда вообще вникать в этот вопрос? Могу назвать несколько причин:

• Хотя оконные функции объективно сложнее обычных агрегатных, но ничего запредельного в них нет; это абсолютно необходимый инструмент для SQL-разработчика. А создание собственной оконной функции, даже совсем простой, позволяет лучше разобраться с тем, как работают стандартные.
  
• Оконные и агрегатные функции — прекрасный способ совместить процедурную обработку с декларативной логикой. В некоторых ситуациях получается выполнить сложные действия, оставаясь в рамках парадигмы решения задачи одним SQL-запросом.
  
• Да и просто интересная тема, а уж тем более интересно сравнить две системы.
  

Пример, на котором будем тренироваться — подсчет среднего, аналог стандартной функции avg для типа numeric (number в Oracle). Мы напишем такую функцию и посмотрим, как она работает в агрегатном и оконном режимах и может ли она вычисляться несколькими параллельными процессами. А в заключение поглядим на пример из реальной жизни.

В прошлых статьях мы рассмотрели механизм индексирования PostgreSQL и интерфейс методов доступа, а также хеш-индексы, B-деревья, GiST, SP-GiST, GIN, RUM и BRIN. Нам осталось посмотреть на индексы Блума.

Bloom

Общая идея

Классический фильтр Блума — структура данных, позволяющая быстро проверить принадлежность элемента множеству. Фильтр очень компактен, но допускает ложные срабатывания: он имеет право ошибиться и счесть элемент принадлежащим множеству (false positive), но не имеет права сказать, что элемента нет в множестве, если на самом деле он там присутствует (false negative).

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

В случае индекса СУБД мы фактически имеем N отдельных фильтров, построенных для каждой индексной строки. Как правило, в индекс включаются несколько полей; значения этих полей и составляют множество элементов для каждой из строк.

Благодаря выбору размера сигнатуры m, можно находить компромисс между объемом индекса и вероятностью ложного срабатывания. Область применения Блум-индекса — большие, достаточно «широкие» таблицы, запросы к которым могут использовать фильтрацию по любым из полей. Этот метод доступа, как и BRIN, можно рассматривать как ускоритель последовательного сканирования: все найденные индексом совпадения необходимо перепроверять по таблице, но есть шанс вовсе не рассматривать значительную часть строк.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Релизы

Вышел релиз PostgreSQL 10.2
В списке исправлений десятки пунктов. Например: устранение сбоев параллельных процессов при использовании более чем одного узла Gather (Томас Мунро) или Изменение поведения оператора cube ~> int в расширении contrib/cube для обеспечения его совместимости с поиском kNN(Александр Коротков). Одновременно вышли исправления версий 9.x. Напоминаем, что в новой нумерации 10.2 это минорный релиз.
Postgres Pro 10.2.1 Standard
доступен на сайте Postgres Professional Выпуск включает все новые возможности, появившиеся в PostgreSQL 10, а также исправления ошибок, вошедшие в PostgreSQL 10.2. Среди исправлений уже от Postgres Professional:

• Утилита pg_probackup обновлена до версии 2.0.14 (исправлено поведение ptrack и резервного копирования страниц в условиях гонки; исправлено прерывание параллельного резервного копирования ptrack); добавлено новое состояние резервного копирование (ORPHAN), указывающее, что одна из предыдущих резервных копий испорчена.
• Обновлён модуль pg_variables.
• Модуль pg_pathman обновлён до версии 1.4.9. В этой версии исправлена обработка ONLY во всех типах запросов.

Подробности здесь.
2ndQuadrant объявила о выходе версии OmniDB 2.5
Новая версия графического клиента PostgrSQL приблизилась к заявленной цели: стать универсальным клиентом БД. Объявлено, что в новой версии есть базовая поддержка Oracle: можно управлять, соединяться и взаимодействовать с базами Oracle, использовая бóльшую часть функционала, доступного для пользователей PostgreSQL. Появилась новая панель DDL. Релиз 2.5 сопровождался серией статей, например: Oracle with OmniDB ключевого разработчика Вильяма Ивански.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL. Первый выпуск был почти месяц назад. Наш второй выпуск собрал в полтора раза больше материалов, а к существующим разделам добавился новый – книги о Постгресе и технологиях БД.

Релизы и коммиты

• Cybertec объявил выход pgconfigurator — визуального конфигуратора для редактирования файла postgresql.conf. Можно настраивать:
  • параметры репликации;
  • параметры, связанные с контрольными точками;
  • ввод/вывод, оптимизировать параллельные запросы;
  • конфигурировать память.
• Devart предлагает dbForge Studio for PostgreSQL — графическую среду для работы с базами данных и объектами PostgreSQL.
• Вышла версия JDBC 42.2.0
  Новое:
  • поддержка SCRAM-SHA-256 для PostgreSQL 10 в версии JDBC 4.2 (Java 8+),
  • используется библиотека Ongres SCRAM library;
  • Make SELECT INTO и CREATE TABLE AS теперь возвращает клиенту число строк.
  • поддержка Subject Alternative Names для SSL-соединений
  • поддержка isAutoIncrement в метаданных для столбцов идентификации в PostgreSQL 10;
  • поддержка массивов примитивов;
  • появилась поддержка get/setNetworkTimeout() в соединениях;
  • в Make GSS JAAS теперь логин не обязателен; добавлена опция «jaasLogin»

В прошлых статьях мы рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа и следующие методы: хеш-индексы, B-деревья, GiST, SP-GiST, GIN и RUM. Тема этой статьи — BRIN-индексы.

BRIN

Общая идея

В отличие от индексов, с которыми мы уже познакомились, идея BRIN не в том, чтобы быстро найти нужные строки, а в том, чтобы избежать просмотра заведомо ненужных. Это всегда неточный индекс: он вообще не содержит TID-ов табличных строк.

Упрощенно говоря, BRIN хорошо работает для тех столбцов, значения в которых коррелируют с их физическим расположением в таблице. Иными словами, если запрос без предложения ORDER BY выдает значения столбца практически в порядке возрастания или убывания (и при этом по столбцу нет индексов).

Метод доступа создавался в рамках европейского проекта по сверхбольшим аналитическим базам данных Axle с прицелом на таблицы размером в единицы и десятки терабайт. Важное свойство BRIN, позволяющее создавать индексы на таких таблицах — небольшой размер и минимальные накладные расходы на поддержание.

Работает это следующим образом. Таблица разбивается на зоны (range) размером в несколько страниц (или блоков, что то же самое) — отсюда и название: Block Range Index, BRIN. Для каждой зоны в индексе сохраняется сводная информация о данных в этой зоне. Как правило, это минимальное и максимальное значения, но бывает и иначе, как мы увидим дальше. Если при выполнении запроса, содержащего условие на столбец, искомые значения не попадают в диапазон, то всю зону можно смело пропускать; если же попадают — все строки во всех блоках зоны придется просмотреть и выбрать среди них подходящие.

Не будет ошибкой рассматривать BRIN не как индекс в обычном понимании, а как ускоритель последовательного сканирования таблицы. Можно посмотреть на него и как на альтернативу секционированию, если каждую зону считать отдельной «виртуальной» секцией.
Теперь рассмотрим устройство индекса более подробно.