БЕТА 14

PostgreSQL 14 beta

Вышла первая бета PostgreSQL 14, а затем и вторая (здесь отличия 1-й беты от 2-й, они незначительные). Дальше будет ещё, возможно, несколько бета-релизов, потом один или несколько релиз-кандидатов и — в конце сентября 2021-го — официальная PostgreSQL 14.

Загрузить
Информация для бета-тестеров
Новое в PostgreSQL 14
Нерешённые проблемы PostgreSQL 14
Найдите баг. И пришлите.

Вместо эпиграфа слова Брюса Момджана:
в предыдущих четырёх в мажорных релизах было от 170 до 189 пунктов с новшествами, а здесь — 222. Такое случалось разве что до 2017 года.

Что делать с такой горой информации?

Первый совет наш обычный: не ждите релиза, читайте уникальные (не только для русского контекста) обзоры принятых коммитов от Павла Лузанова. Это энциклопедия новшеств. С примерами. Можно увидеть и динамику — что когда приняли. Вот все 5 частей по коммитфестам, имеющим отношение к версии 14:
Июльский,
Сентябрьский,
Ноябрьский,
Январский,
Апрельский.

Кроме того, на этот раз можно посмотреть, например, ещё вот какие источники: микро-обзоры Мишеля Пакье (Michael Paquier) в серии Postgres 14 highlights. Пока их вышло пять:

Monitoring for COPY

COPY TO и COPY FROM нередко занимают много времени, поэтому возможность посмотреть, как идут дела с копированием, не прихоть. В новом системном представлении pg_stat_progress_copy по одной строке с 8 полями (см. статью) на каждый бэкенд.

Memory dumps

PostgreSQL работает с памятью в рамках программной архитектуры контекстов. Представление pg_backend_memory_contexts позволяет заглядывать в память, доступную сессии, не используя дебаггер, (это особенно полезно в облачных средах) начиная с TopMemoryContext и спускаясь по деревьям. Это можно сделать не только от суперюзера, но и от ролей, которым это дозволено по GRANT. Кроме того, добавлена одноименная функция pg_backend_memory_contexts(), которая может заглядывать и в чужие сессии (она только под суперюзером). Значения не возвращаются клиенту, а сбрасываются в лог.

REINDEX TABLESPACE

Это значит, что индекс можно перемещать CONCURRENTLY, так как индекс можно перестраивать, перемещая в другое табличное пространство, а не в два этапа: перестройка, потом перемещение — меньше вероятность, что пространства не хватит. При этом разрешая одновременное чтение и запись во время переиндексации, поскольку операция накладывает блокировку SHARE UPDATE EXCLUSIVE на индекс и родительскую таблицу. Подобная судьба (добавка CONCURRENTLY) ждала CLUSTER и VACUUM FULL, но не дождалась: релиз вышел.

Fun with Hashes

Здесь даже есть небольшой исторический экскурс в криптографию Postgres.

CREATE TABLE COMPRESSION

Тоже с историей вопроса. Сейчас SET COMPRESSION можно задать как lz4. По умолчанию GUC default_toast_compression = «pglz».

Интересная ситуация с репликацией: при физической репликации можно проигрывать на реплике WALы ведущего сервера, сжатые LZ4, даже если реплика не поддерживает LZ4. Но прочитать данные из таких таблиц не получится: Postgres выдаст ошибку. При логический репликации на каждом сервере всё будет сжато в соответствии с настройками сервера.

Не один Пакье писал о 14-й, конечно. Есть серия Хуберта «Депеша» Любашевского:
В ожидании PostgreSQL 14, но о нём мы и так часто пишем (и в этом выпуске тоже).

Алексей Лесовский выбрал одну категорию: Что нового в плане мониторинга в PostgreSQL 14.

Ещё обратите внимание, что появился интересный, основательный документ от HPE:
PostgreSQL 14 New Features With Examples (Beta 1)

Ещё о PostgreSQL 14: Turning 100 Lines of SQL Into 3

Джонатан Кац (Jonathan S. Katz, Crunchy Data) пишет о мультидиапазонах (multirange) — в PostgreSQL 14 именно они упростили ему и упростят многим их SQL-жизнь: приводит пример «из жизни» — с бронированием встреч. Действительно всего 3 строчки нужно для того, чтобы посмотреть, какие дни свободны. Сначала, конечно, надо забить необходимые данные в таблицу, но сложный рекурсивный запрос не потребуется.

Про мультидиапазонные типы данных довольно развёрнуто пишет и Павел Лузанов в 4-й части коммитфест-обзоров, которых мы упоминали в самом начале.

Ну а Деврим Гюндюз (Devrim Gunduz) поможет установить 14-ю версию из rpm: Installing PostgreSQL 14 beta/RC on RHEL / Rocky Linux / Fedora and SLES. До этого он помогал поставить PostgeSQL на Rocky Linux 8 (ОС класса enterprise, разработанная сообществом так, что она 100%, с точностью до багов (bug-to-bug) совместима Red Hat Enterprise Linux).

Вместо эпилога: Some Interesting statistics about PG-14 contributions

Асан Хади (Ahsan Hadi) из HighGo решил собрать статистику по коммитам в PostgreSQL 14. Дело доброе: до него этим любил побаловаться Роберт Хаас (Robert Haas), но он считал по годам. Вот его подсчёты:
за 2019
за 2018
за 2017
за 2016
и — главное — за 2020-й статистики пока не было. А Асан посчитал и даже построил 3D-диаграммку: разбивка по странам. Хотя хвост списка стран выглядит немного странно: Амстердам, Польша, Цюрих, Швейцария. Ладно, столбик России возвышается над многими, уступая только США, Японии, Индии и Чехии (усилия Томаша Вондры — Tomas Vondra — и Павла Штехуле — Pavel Stehule).

Postgres Professional соревнуется с Microsoft, проигрывая EDB, Crunchy Data, NTT, Fujitsu, VMware, зато сильно опережая AWS и многих других.

Также есть разбивка по категориям и по авторам.

До того, как стать вице-президентом по разработкам в китайской HighGo Асан работал старшим директором по продукту Postgres Plus Advanced Server.

Кстати, его выбор top7 фич PostgreSQL 14:

1. Asynchronous execution of PostgreSQL_FDW Append node
2. Improving connection scalability: GetSnapshotData() [это правильная ссылка, в статье битая]
3. Overhaul UPDATE/DELETE processing (making update/delete of inheritance trees scale better
4. logical streaming for large in-progress transactions
5. Add support for multirange data types
6. Allow btree index additions to remove expired index entries to prevent page splits
7. PostgreSQL_FDW Batching

Теория

What does First Normal Form actually mean?

Неожиданная статья. Во времена, когда разработчики, гонясь за производительностью, то и дело отказывают от того или другого уровня, автор с необычной фамилией Галиматьяс (sic! Galimatias) предлагает разобраться в тонкостях определений, данных Эдгаром Коддом для 1-й Нормальной Формы (1NF).

По Галиматьясу, путаница с нормальной формой 1 происходит сразу по нескольким пунктам, которые разбирает Галиматьяс:

• 1NF говорит о недопустимости строк с значениями, разделёнными запятой;
• 1NF говорит о недопустимости нескольких столбцов одного типа;
• 1NF не должно быть строк с одинаковыми значениям;
• 1NF говорит об обязательности primary key.

Галиматьяс говорит:
Для эксперимента я погуглил first normal form, и во ВСЕХ результатах первых двух cтраниц выдачи были неправильные объяснения, включая самое первое — википедию (правда там теперь поправили). Поправили в английской, разумеется, а не в русской. Теперь там 1NF определение правоверное, по Кодду: Отношение находится в первой нормальной форме тогда и только тогда, когда в домене атрибута ни один элемент не содержит отношения.[A relation is in first normal form if and only if no attribute domain have relations as elements]

В русской вики немного другая формулировка:
Переменная отношения находится в первой нормальной форме тогда и только тогда, когда в любом допустимом значении этой переменной [домене] каждый кортеж отношения содержит только одно значение для каждого из атрибутов [Date on Database. Writings 2000-2006].
Но русская вики и не собиралась следовать Кодду. Она опирается, скорее, на Кристофера Дейта. Про атомарность там, например, цитируют именно его:
концепция атомарности [введённая Коддом] является слишком неясной [Введение в системы баз данных — книга К.Дейта)]. Например, многие типы данных (строки, даты, числа с фиксированной точкой и т. д.) при необходимости легко могут быть декомпозированы на составляющие элементы с помощью стандартных операций, предоставляемых СУБД. К. Дейт заключает, что понятие атомарности не имеет абсолютно никакого смысла.

Но вернёмся к коддовскому определению 1NF. Галиматьяс отсылает к истории СУБД. И становится понятно, зачем понадобилось условие недопустимости отношений как элементов отношения, которое нам, привычным к РСУБД, уже кажется само собой разумеющимся: до РСУБД мейнстримом были иерархические СУБД, а какая ж иерархия без вложенных друг в друга отношений?

Автор то и дело заныривает в историю СУБД и доставляет на поверхность правильное понимание 1NF и процессов нормализации. Уточнение: правильное в понимании Э. Кодда.

Новости IT-лингвистики

Неожиданный лингвистический поворот и круговорот вызвало предложение Дэвида Роули (David Rowley) разобраться с артиклями a vs. an в a(n) SQL. Вопрос отчасти исторический: SQL одно время произносили как «сиквел» (отсюда «э сиквел»), но потом бросили это несколько искусственное произношение, он стал «эскюэл» («эн эскюэл»). Однако в документах и комментариях к коду попадаются оба варианта. Дэвид предложил решить раз и навсегда и устранить путающее разнообразие. Сам он за an. Десятки реплик в переписке подтвердили, что вопрос не пустой. Заодно обратили внимание на аналогичные конструкции:

a(n) SASLResponse message
a(n) SHA1 hash
a(n) MIT Kerberos

Мнения разделились по поводу главного: стоит ли вообще беспокоиться на этот счёт. Том Лейн (Tom Lane), например, считает, что вряд ли. Но он, кажется, не в большинстве.

Из жизни контрибьюторов

How (and why) to become a PostgreSQL contributor

Александр Алексеев, известный также как afiskon поделился в блоге Timescale, где он теперь работает, своими соображениями о том, как стать контрибьютором в PostgreSQL и надо ли.

Александр автор расширений pg_protobuf and ZSON и нескольких открытых библиотек для микроконтроллеров STM32 (на ARM).

Я люблю открытый код как раз потому, что мы можем заглянуть в этот код и поучиться на написанном, потом улучшить его. Стандарты качества здесь высоки — ведь нельзя спрятать халтуру — в отличие от проприетарного софта.

На русском Александр писал на эту тему, но несколько лет назад. Новый виток сразу на английском.

1. Разберитесь со своей мотивацией;
2. вникайте в процессы разработки;
3. определитесь: который из ваших патчей будет первым;
4. как избежать типичных ошибок контрибьютора;
5. подумайте о вкладе не только в код;
6. дополнительные ресурсы для изучения;
7. выводы в конце

Цель статьи — помочь будущим контрибьюторам помочь перейти из категории контрибьюторов «никогда» к «1 или 2 раза», а потом, может, и к «много раз».
В статье Александр ссылается на исследование, которое проводили в его компании:

State Of PostgreSQL 2021

Симпатичное исследование-опрос. Вопросов много, ответы можно пролистнуть в виде диаграмм с 3 ответами-лидерами, а можно посмотреть более детальную картину, где дюжина ответов или около того.

Начнём с вопроса не технического: как вы называете родную СУБД? Postgres или PostgreSQL? Оказывается, 65.2% называют её Postgres и лишь 21.6% — PostgreSQL, а 7.2% опрошенных всё равно. Диаграммы, впечатлившие Александра: 85% респондентов из сообщества никогда не контрибьютили ни кода, ни ревю, ни доков; 11% — раз или два; и только 4% — много раз (методология опроса там же).

80% в сумме ответили, что используют у себя в компании Postgres больше, чем раньше / намного больше. Из технического: среди расширений лидеры: PostGIS, timescale, pg_stat_statesments; среди графических сред лидирует Grafana, от неё немного отстаёт ответ «графических не использую вообще»; самые востребованные возможности SQL в продакшн — CTE, оконные функции, выражения-фильтры при агрегации; для организации данных и доступа к ним несомненный лидер JSON(B).
Какие решения автоматизированного фейловера вы используете? — да никакие! — отвечают 68%. Следующий ответ Patroni, дальше repmgr, Stolon только 5-й.
В облаках AWS с 46% опережает почти втрое ближайшего — GCP. Не обращались к облачным провайдерам 26%.

Можно сравнить с ответами 2 года назад на примерно те же вопросы, только без нынешних красот.

Практика

Отказоустойчивый кластер PostgreSQL с помощью crm

Обстоятельная статья инженера Postgres Professional Игоря Косенкова. В ней на этот раз фокус внимания не на Postgres, а на собственно кластерных технологиях. Прежде всего на crm — cluster resource manager — специальной утилите, которая используется для создания и управления отказоустойчивым кластером. Она включена в пакет crmsh, который обычно не входит в состав самых распространенных дистрибутивов Linux. crm не так широко известна, как pcs. А зря — считает автор.

Демонстрация проводится на 3 узлах с CentOS 7.9, с пакетами corosync, pacemaker, fence-agents* и csync2; для crmsh нужно подключить репозиторий Extra OKay Packages for Enterprise Linux. Все этапы подробно расписаны, а в конце показан альтернативный вариант — без пакета csync2.

Хорошие новости для тех, кто всё ещё использует row-level локи в PostgreSQL

Дмитрий Васильев aka vadv из Ozon Tech пишет об издержках row-level locks — блокировок на уровне строки (FOR SHARE, FOR UPDATE, рекомендательные — advisiry locks). Зачем они, как их наблюдать, как они влияют на производительность? Исследуется это всё на 4-ядерной виртуальной машине с 4 ГБ памяти. В статье много примеров, схемы, флеймграфы.
Выводы:
блокировки row-level

• вызывают перезапись страницы, даже FOR SHARE;
• используют MultiXact, которые по факту представляют из себя ещё один счётчик, wraparound которого обслуживает vacuum наравне с обычным счетчиком транзакций;
• добавляют ещё задержек из-за обслуживания связки «MultiXact» <-> «массив обычных xid» и этот вклад существенный – может составлять до x4 и зависит от данных, железа и параметров использования;
• сам факт использования MultiXact вызывает дополнительный оверхед при манипуляции с данными, с которыми работают row-level локи.

Блокировки advisory:

• не являются полной заменой row-level локов и потребуют изменения вашего кода;
• переход на advisory локи увеличат производительность вашего приложения.

Возможно, перед чтением этой статьи имеет смысл почитать статью Егора Рогова
Блокировки строк из сериала Блокировки в PostgreSQL.

1. блокировки отношений;
2. блокировки строк;
3. блокировки других объектов и предикатные блокировки;
4. блокировки в оперативной памяти.

Global Temporary Table in PostgreSQL

Статья Жиля Дароля (Gilles Darold) в блоге MigOps, в которой он рассказывает,
для чего (чтобы облегчить миграцию с Oracle, где есть глобальные временные таблицы)
и как (концепция GTT в Postgres) разрабатывал расширение PGTT,
как его инсталлировать и использовать (много примеров-листингов),
а также о том, что его расширение не может сделать (системный каталог может пухнуть, но есть другой вариант расширения — PGTT-RSL — с нелогируемой таблицей и Row Security Level, там каталог не распухает, но ценой того, что оно работает медленней, чем PGTT).

Вот последняя на данный момент версия: Global Temporary Table v2.4
В ней можно создавать, поддерживать и использовать pgtt не обязательно под суперюзером. Поддерживает PostgreSQL v14. Полный список изменений там же.

PostgreSQL benefits and challenges: A snapshot.

Статья Ивана Панченко (зам. гендир. Postgres Professional) в InfoWorld о том, как PostgreSQL движется в сторону корпоративного софта, справляющегося с самыми сложными и критичными сценариями использования (use cases). Yandex хранит в PostgreSQL петабайты данных и справляется с 150 млн. писем в день, кластер GitLab обрабатывает 181 тыс. транзакций в секунду, у IKEA есть несколько терабайтных баз, а у InCountry распределенная глобальная база данных с data-residency-as-a-service. О последнем случае расскажу попозже, это любопытно.

Жанр статьи не предполагал экскурсов в технологические глубины, поэтому просто перечислю пункты, которые Иван выделил. Преимущества: качество кода (многочисленные ревю); расширяемость; SQL & NoSQL (JSON); пространственные данные (PostGIS); доступность, жизнестойкость данных (availability & resiliency) и информационная безопасность – для высоко-критичных задач дополнительные нужные свойства можно найти в версиях Postgres, поддерживаемых частными компаниями. Преимущества PostgreSQL над другими опенсорсными проектами: управляется не единственным вендором; не привязывает (no lock-in) к одному вендору (нет стратегии подсадить на сопутствующие продукты — облачные DBaaS, например); популярность – влияние на отраслевые стандарты, легче найти специалиста.

Чуть подробней о том, с какими проблемами можно столкнуться:

• Затраты — миграция и поддержка стоят денег, и лучше сразу общаться с консультантами, чтобы избежать неприятных сюрпризов.
• Время — проекты по разработке или миграции могут потребовать больше времени из-за исследования проблем, обнаружившихся по ходу, лучше закладывать их в проект с самого начала.
• Управляется не единственным вендором — да, этот пункт есть и в списке достоинств. Например: для PostgreSQL есть 5 утилит резервного копирования от разных компаний, значит надо потратить время на сравнение, или — это разумней — попросить совета у консультанта.
• PostgreSQL у себя (on-premises) vs. в облаке – многие расширения PostgreSQL в облаке могут оказаться недоступны. Облачные расходы тоже могут оказаться немаленькими. Многие компании поэтому отказались от облаков и вернулись к собственным ресурсам.
• Размер инсталляции — перейти на Postgres маленьким компаниям несложно, а вот средним и большим при миграции может понадобиться поддержка вендора или консультантов по миграции.
• Эксперты в своей компании — для работы с любой СУБД нужны специалисты. Надо оценить: нанимать ли специалистов, растить ли их у себя.

Теперь об InCountry, направлении ИТ, имеющем прямое отношения к местным проблемам. Компания предоставляет услуги DRaaS — термин, которого даже в вики ещё нет (точнее, там есть, но Disaster-Recovery-aaS). Смысл data-residency-as-a-service в том, что провайдер этого сервиса обеспечивает обращение с хранимыми данными (прежде всего персональными) в соответствии с законодательством стран. Именно обращение, а не хранение — они могут, например, храниться в датацентрах в одной стране, но, эти центры, будучи собственностью другой, подпадают под законодательство хозяев. Передача данных в SaaS-приложения — в основном глобальные по сути — тоже может быть регламентирована причудливым образом. В InCountry отмечают, например, строгость законов Австралии и Евросоюза, но больше всего, кажется, впечатлены жёсткостью наших законов о защите персональных данных. Тем не менее, или тем более, у InCountry уже есть российская штаб-квартира в Ростове. А сотрудничают они, например, с Yandex.

Измеряем расходы на память у Postgres процессов

Алексей Лесовский (вольно, как он признаётся) перевёл опубликованную осенью прошлого года статью Андерса Фройнда (Andres Freund):
Measuring the Memory Overhead of a Postgres Connection. Об этой статье мы писали в Postgresso 26 и обращали внимание вот на что:
Для более тонких замеров памяти Андрес использует системные /proc/$pid/status и /proc/$pid/smaps_rollup. Так можно увидеть значения VmRSS, VmRSS, RssAnon, RssFile, RssShmem — если вы не знали, что это, то из статьи узнаете и поймёте, почему они важны. Чтобы не обмануться с причиной перерасхода памяти, он замеряет с включенным и отключенным huge_pages. Ещё: надо помнить о copy-on-write при форке процесса.

Под переводом примечание Лесовского:
В версии Postgres 14 появилось новое представление pg_backend_memory_contexts которое показывает подробную утилизацию памяти текущим процессом с точки зрения самого Postgres.

A tale of making company-wide standard psqlrc

Хуберт «Депеш» Любашевский (Depesz) пишет на этот раз о своём наболевшем — как он, будучи DBA, управляется с тысячами (!) БД в AWS (ещё и pgbouncer-ы впереди). Базы с одинаковыми названиями, но разными данными. Чтобы не запутаться, заходя по psql, Депеш решил написать скрипт, который исполняется при входе на сервер — .psqlrc. Он вытягивает информацию о том, что за сервер, какое окружение, как называется кластер, и функцию, которую он выполняет, и пишет всё это в prompt. Скрипт получился с IF — ELSE и в нём 30 с лишним строк.

Некоторые релизы

pgCenter 0.9.0

В новой версии этого софта для администрирования воспользовались в том числе возможностями появившимися в свежей бете:

• статистика сессии из pg_stat_database (для Postgres 14);
• статистика использования WAL из pg_stat_wal (для Postgres 14);
• статистика состояния копирования комманд с COPY — из pg_stat_progress_copy (для Postgres 14);
• статистика файловой системы для top;
• расширенная статистика о размере таблиц;
• поддержка миллисекундного разрешения для отчётов;
• naming convention для названий столбцов.

pgAdmin4 5.3 и 5.4

Из нового, например:

• аутентификация по Kerberos при установке соединения;
• можно запустить psql при соединении;
• инсталляция не под админом в Windows;
• добавили ротацию логов по критериям LOG_ROTATION_SIZE или LOG_ROTATION_AGE — по размеру / по старости.

Вышли новые FDW от Toshiba Software Engineering & Technology Center. Ссылка в заголовке — на гитхаб, а наиболее полные описания, с особенностями релиза, — на postgresql.org. В основном это новые пуш-дауны:

InfluxDB fdw 1.0.0
на postgresql.org.

SQLite fdw 2.0.0
на postgresql.org.

griddb_fdw 2.0
на postgresql.org

Новость из Поднебесной:
PolarDB for PostgreSQL

Не берёмся дать внятную оценку этой во многом пока загадочной СУБД, о которой впервые публично доложили в 2018-м. Теперь открыли код. Это одна из разработок китайцев с Ali — на их гитхабе 13 страниц проектов, но этот не затерялся. О нём пишет, например, База данных баз данных (Database of Databases).

Заявлено, что PolarDB это распределённая share-nothing база, обеспечивает глобальную согласованность и ACID по всем узлам. Использует Paxos для синхронизации данных при репликации.

Дополнительную функциональность можно в основном получить, установив расширения, но всё же патчи ядра нужны, например, для распределённого MVCC различных уровней изоляции. Узлы хранения общаются с вычислительными узлами по RDMA.

pgSCV 0.5.0

Проект Алексея Лесовского, агент для мониторинга, совместимый с Prometheus, умеющий экспортировать метрики. Работает с PostgreSQL и с инструментами его экосистемы. Новое в версии:

• широкий набор встроенных метрик по работе системы, PostgreSQL и сервисов Pgbouncer;
• в Pull-режиме: pgSCV слушает /metrics и обслуживает запросы с Prometheus или Vmagent (Victoriametrics);
• в Push-режиме: pgSCV сам отправляет собранные метрики HTTP-сервисам (сделано для Weaponry SaaS, но пригодится и для другого);
• авто-определение локальных сервисов;
• поддержка удалённых (remote) сервисов;
• пользовательские метрики

pgSCV на Github
pgSCV-wiki
Коллекторы
Метрики

PL/R 8.4.2

У PL/R не столько поклонников, как у самых ходовых PL, но много поклонников страстных. В комментарии к статье Cтатистический анализ в PostgreSQL с помощью PL/R Юрий Жигадло aka itcoder говорит следующее: для сложного анализа данных просто бесценное расширение, особенно порадовала отрисовка картинки сразу из запроса, по сути можно в рантайме выбирать данные с хитрыми условиями за нужный диапазон смотреть как будет изменяться диаграмма. Интересно конечно как без PL/R сейсмологи данными оперируют?

О расширении PL/R можно почитать на сайте автора — Джо Конвея (Joe Conway). И на гитхабе.

В версии 8.4.2 добавлены транзакции в процедурах; поддержка пользовательских типов (tuple) в оконных функциях; сборки Windows теперь с R 4.10.0.

WAL-G 1.0

У WAL-G появилась версия 1.0, совместимая с 0.2.0 и выше. WAL-G научился восстанавливать бэкапы и WAL, сделанные WAL-E. Научился делать удалённые бэкапы. Готов к продакшн на MS SQL и MySQL, а в бета-фазе поддержка MongoDB и Redis. И вообще в 1.0 много всего.

Персона: Николай Самохвалов

Николай стал персоной недели. Это интервью не похоже на многие другие в Персонах недели: неформальное и развёрнутое — раз в 10 больше букв, чем обычно.

Начинал Николай с создания софта для соцсетей MoiKrug.ru, MirTesen.ru и Postila.ru.

— Какие новшества ваши любимые в последних версиях PostgreSQL?
Н.С.: Оптимизация Btree в Postgres 12 и 13 (заслуга Питера Гейгана (Peter Geoghegan), Анастасии Лубенниковой [тоже, кстати, побывала в Персонах], и других). А ещё улучшения в диагностических инструментах: новые данные в pg_stat_statements, вывод EXPLAIN, новые варианты в сэмплинге логов.
К сожалению, не вижу пока PostgreSQL 13 в высоконагруженных проектах. Спросите меня ещё разок через пару лет.

— Ваше любимое расширение?
Н.С.: pg_stat_statements: люблю и ненавижу!

— Что больше всего раздражает в PostgreSQL?
Н.С: 1. устаревшие средства разработки, 2. то, что по умолчанию в EXPLAIN ANALYZE не показываются BUFFERS, 3. VACUUM и распухание индексов и таблиц (bloat) раздражает всех, меня тоже, зато без работы мы не останемся :)

Конференции

PGDayRussia 2021 состоится онлайн 8-9 июля. 2 дня, 12 выступлений, Q&A-сессии.
Анонсы выступлений, актуальное расписание и ссылки на прямую трансляцию — в Slack канале конференции.
Участие бесплатное.
#PostgreSQL — в Facebook

Postgres Vision

Эта онлайновая и бесплатная конференция состоялась 22-23 июня. Россия представлена была Олегом Бартуновым. Он рассказал о масштабировании JSONB (Scaling Jsonb). Можно заполнить форму и получить.

В расписании были такие темы как Deconstructing Postgres into a Cloud Native Platform Альваро Эрнандеса (Alvaro Hernandez, OnGres) OtterTune: An Automatic Database Configuration Tuning Service Энди Павло (Andy Pavlo, Университет Карнеги Меллона)
What's new in PostgreSQL 14? Роберта Хааса (Robert Haas, EDB)
Columnar storage options for PostgreSQL Себастьяна Дресслера (Sebastian Dressler, Swarm64).
(Не проверял, все ли они прозвучали в результате).

Вебинары и митапы

Деятельность Postgres Professional, направленная на мировую аудиторию, видна и по серии англоязычных докладов её разработчиков и инженеров. Это стоит послушать и на английском, вещи рассказываются не маркетинговые, а технически насыщенные.

Доступна запись совместного доклада How to do database audits for PostgreSQL? Андрея Зубкова (его часть называлась pg_profile — PostgreSQL historic workload reporting tool) и Петра Петрова (Configuration settings and diagnostic tools for better PostgreSQL performance), состоявшегося 11-го мая. Очень рекомендую обоих авторов. Доступен и очень содержательный доклад How to optimize database queries in PostgreSQL? Петрова 17-го июня.