Новые контрибьюторы PostgreSQL:

• Бертран Друво (Bertrand Drouvot),

• Габриэль Бартолини (Gabriele Bartolini),

• Ришар Гуо (Richard Guo).

Новые главные (major) контрибьюторы PostgreSQL, прибавилось два представителя Microsoft и один от Amazon:

• Александр Лахин (Alexander Lakhin) - особенно поздравляем!

• Дэниэл Густафссон (Daniel Gustafsson, Microsoft),

• Дин Рашид (Dean Rasheed),

• Джон Нэйлор (John Naylor),

• Мелани Плейгман (Melanie Plageman, Microsoft),

• Натан Боссарт (Nathan Bossart, Amazon Web Services).

Всех поздравляем! Страница контрибьюторов здесь.

Who's in Charge?

Боюс Момджан недавно разъяснял: много кто причастен к управлению делами Postgres. Не только Core Team. И даже выкатил целый список институций и коллективов внутри сообщества:

• коммитеры;

• участники рассылки hackers;

• контрибьюторы;

• команда Planet Postgres;

• модераторы IRC-канала;

• организаторы мероприятий;

• организаторы пользовательских групп (user groups);

• совет по торговым маркам (trademark board);

• финансовая группа (funds group);

• инфраструктурная команда;

• команда безопасности;

• комитет нравственного кодекса (code of conduct committee).

The State of the Database Landscape 2024

Аналитики Redgate сообщает, что в их обзоре поучаствовали 3849 респондентов с 6 континентов, представляющие 15 секторов индустрии.

Они выделяют как важный тренд то, что заметно (с 62% в 2020-м до 79% в 2024) и неуклонно увеличивается число тех компаний, у которых 2 и более платформ. Это коррелирует с потребностями рынка рабочей силы: всё быстрей требуется менять навыки и/или разнообразить их.

Ну а лидирующие платформы всё те же: SQL Server, Oracle, MySQL и Postgres. Там несколько диаграмм, ничего особо сенсационного, кажется, нет.

Облака используют уже 88%, а 36% используют в основном облака или только облака (в 2020-м таких было всего 18%). Но при этом некоторые их используют ограниченно, и причина в 24% случаев в расходах - оказалось не так уж выгодно, в 14% случаев озабочены безопасностью, а в 6% случаев это связано с вендором или клиентом.

The Future of Databases. 8 Data Management Trends

В блоге Budibase, автор Ронан Макквиллан (Ronan McQuillan). Тренды таковы:

1. serverless - в качестве примера - PlanetScale (она на базе MySQL) и SupaBase (на базе Postgres), нашей любимой Neon нет.

2. cloud-native - пример: интерфейс Fauna, вдохновлённый примером TypeScript.

3. Ветвление (Branching) - а вот здесь и выходит, наконец, на сцену Neon (жаль, что о Database Lab Engine забыли);

4. Мультимодельные - SurealDB, Couchbase Capella - первый раз слышу о таких, честно говоря;

5. Графовые - Memgraph — это решение для графовых баз данных, которое представляет собой более производительную и быструю альтернативу Neo4j;

6. Базы данных временных рядов - здесь наверняка о Timescale? Ан нет, в этом пункте InfluxDB;

7. Внедрение искусственного интеллекта (AI) в базы данных - MindsDB — это база данных, ориентированная на искусственный интеллект (AI). Она интегрируется со множеством различных источников данных, таких как Slack или Shopify, Postgres и другие. MindsDB также может получать данные в реальном времени и применять к ним методы машинного обучения и AI.

8. low-code разработка - BudibaseDB - разработку их компании они скромно поместили на 8-е место. BudibaseDB предоставляет специальные коннекторы для создания пользовательских интерфейсов и процессов на основе Postgres, MySQL, MSSQL, Couch, Mongo, Arango, S3, Oracle, Google Sheets, REST API и многих других — наряду с поддержкой пользовательских источников данных.

Hello DBOS - Announcing DBOS Cloud

Майкл Стоунбрейкер объявил, что пора перевернуть пару ОС/СУБД вверх ногами: теперь не база будет поверх операционной системы, а наоборот: ОС поверх СУБД. Что в этом заявлении от маркетинга, а что от технологий, пока сказать трудно, но очевидно, что как минимум его DBOS (Database-Oriented Operating System) с самого начала разрабатывалась для поддержки больших распределённых приложений в облаке, что ОС знает о том, что делается в базе, умеет путешествовать во времени (согласованно откатывать до заданного состояния), что архитектура бессерверная, все операции с данными ОС делаются транзакционно.

И как можно больше сервисов, традиционно выполняемых ОС, делается средствами базы. В любой современной ОС и так много делается средствами баз поверх ОС. Вот, например, что пишет Microsoft:

Резервное копирование состояния системы: резервное копирование файлов операционной системы, обеспечивающее сценарий восстановления, когда компьютер запускается, но системные файлы и реестр утрачены.

А в DBOS

1. Все приложения и состояния ОС хранятся в таблицах распределённой ОС.

2. Любой доступ к состояниям только через транзакции базы.

Конечно, Майкл подключил к разработке академические институции. Для получения прототипа он вместе с Матеем Захарией (Matei Zaharia) запустил опенсорсный проект, объединивший студентов/аспиратнов Стенфорда и MIT.

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

PostgreSQL 16.2

В минорном релизе PostgreSQL 16.2 главное это заделывание обнаруженной дыры. Она не такая уж широкая: в принципе владелец материализованного представления мог исполнить код суперпользователя во время выполнения команды REFRESH MATERIALIZED VIEW CONCURRENTLY. Это не работает в 16-й версии, а теперь не работает нигде - уязвимость
CVE-2024-0985 закрыта. В версии были доделки и исправления, они перечислены здесь. Вместе с ними вышли 15.6, 14.11, 13.14 и 12.18.

Вышли соответствующие версии Postgres Pro Standard - самая свежая - 16.2.2. За ними последовали выпуски Enterprise.

Состоялся релиз Postgres Pro Enterprise 16

Это пишет CNews. Но там отнюдь не только об Enterprise 16.1.1. В статье рассказывается в том числе о Pluggable TOASTER, о Citus и о том, чем он отличается от Shardman, говорится о двунаправленной репликации active-active в PG 16. О поддержке внешних файлов в виде отдельного типа BFile и о Postgres Pro Superfile, об "управлялке" PPEM.

Postgres Pro Enterprise 16.2.1

Он поддерживает citus. А ещё есть, например, перепланирование запроса в реальном времени. Если какой-либо триггер указывает на его неоптимальное выполнение, запрос можно перепланировать. По умолчанию перепланирование отключено, но его можно включить с помощью параметра конфигурации replan_enable. Добавлено расширение dbms_lob, позволяющее обращаться к определённым частям больших объектов (LOB) или большим объектам целиком и управлять ими. А также расширение apache_age - функциональность для работы с графовыми базами данных.

Обновлены:  biha до версии 1.1, orafce - до 4.9.2, pg_probackup - до версии 2.7.2 Enterprise, pg_repack - 1.5.0, pg_proaudit - до 2.0, а расширение pg_variables теперь предоставляет функциональность итератора для любых коллекций, а также функции для работы с общими переменными-коллекциями. Модуль pgpro_pwr обновлён до 4.4, в которой добавлена поддержка pgpro_stats 1.7, модуль sr_plan тоже был обновлён, в новой версии улучшена производительность и исправлены некоторые ошибки.

Отныне не поддерживаются Rosa Enterprise Linux Server 7 и ОС РОСА «КОБАЛЬТ» (серверная редакция) на платформе РОСА 7.

На рынке появилась распределенная СУБД Shardman для баз данных в сотни терабайт

Представители Postgres Professional рассказали CNews о Shardman - распределенной реляционной СУБД для высоких нагрузок и инсталляций в десятки и сотни терабайт, когда одного сервера недостаточно. Shardman рассчитан прежде всего на OLTP-нагрузки, чем отличается от многих популярных распределённых СУБД.

Кроме горизонтальной масштабируемости, его архитектура предполагает автоматическую репликацию данных каждого шарда. Всё это при строгом следовании ACID. Особенности Shardman:

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

• новейший механизм интерконнекта, отсекающий избыточные TCP-сессии между шардами, снижающий нагрузку на сеть и конкуренцию за ресурсы;

• ускорение работы приложений, имеющих сложную логику на стороне СУБД и повышение общего TPS всей СУБД;

• дополнительные возможностей СУБД Postgres Pro Enterprise: механизм сжатия данных CFS, инкрементальный бэкап на уровне страниц, механизм для резервного копирования PTRACK и расширение pgpro_stats.

Shardman создавался по запросу заказчиков, уже находится в Реестре российского ПО, прошёл сертификацию ФСТЭК и находится на завершающих стадиях тестирования в крупных компаниях нефтегазового и финансового сектора. Доступна документация.

PGMeetup: Shardman

Встреча с CNews произошла 4 марта, а 5 марта Андрей Забелин (старший технический консультант Postgres Professional) рассказывал о Shardman на митапе. Сейчас видео доступно.

Участие было бесплатное, с регистрацией. Вопросов было огромное количество - под сотню. На них отвечал не только докладчик, но и другие сотрудники Postgres Professional (письменно - в комментариях). Ответы на вопросы заняли час - не меньше самого доклада.

Андрей рассказал о:

• горизонтальном масштабировании PostgreSQL,

• архитектуре Shardman,

• как добиться в нём высочайшей производительности,

• о миграции с одиночного PostgreSQL,

• об отказоустойчивости Shardman.

Мартовский код: в чем шансы на успех российских разработчиков в области open source

Статья на эту тему в Forbes.ru, что необычно. Анкетировали 700 участников рынка (независимых, из крупных и не очень компаний) на темы инвестирования, господдержки и так далее. О СУБД конкретно речи нет. ОС упоминаются.

По словам 72% участников индустрии open source, их проекты не располагают источниками финансирования.

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

Во-первых, государство может оказывать финансовую помощь разработчикам, например выделяя гранты (65%). Во-вторых, стимулировать разработчиков и компании различными преференциями для работы над такими проектами (64%).

Из Oracle

PGMeetup. Миграция на СУБД Postgres Pro. Записи выступлений со встречи 13 февраля

На Youtube-канале Postgres Professional опубликованы видео докладов митапа, который состоялся в «Рэдиссон Славянская». Выступили эксперты Postgres Professional, представители «Айбим», «Конвертум», «СДИ Софт» — обсуждали автоматизацию и упрощение миграции, представили кейс перехода на СУБД Postgres Pro.

Опубликованные записи выступлений :

• Опыт автоматизированной миграции продукта СДИ БАЗИС - Александр Лаврентьев («СДИ Софт»)

• Технологии миграции данных из Oracle в Postgres Pro - Максим Емелин (Postgres Professional);

• Реализация архитектуры максимальной доступности в Postgres Pro Enterprise - Андрей Забелин (Postgres Professional);

• Инструменты и технологии миграции на Postgres Pro Enterprise Игорь Мельников (Postgres Professional);

• Опыт миграции НСИ Строительного Комплекса Московской Государственной Экспертизы - Сергей Прохоров (технический директор «Айбим»);

• Возможности и преимущества автоматической миграции с Oracle на Postgres Pro - Алексей Мигуцкий (руководитель отдела миграции баз данных «Конвертум»);

Partitioning by reference - Oracle vs PostgreSQL

Автор статьи - знаменитый Жиль Дароль (Gilles Darold). Оказывается, он теперь технический директор компании HexaCluster.

Секционирование по ссылке даёт возможность делить на секции таблицы по значениям столбцов, которых нет в этой таблице, но есть в таблице по ссылке FOREIGN KEY. В тексте хороший пример.

Поскольку в Postgres секционирования по ссылке нет (и я не видел даже обсуждений этой темы), Жиль предлагает 3 способа симулировать такое секционирование:

1. вообще не секционировать таблицу,

2. копировать колонку в таблицу, которую надо секционировать,

3. использовать хэш-секционирование.

У каждого из способов, конечно, свои недостатки. Жиль рад сообщить, что в Ora2Pg 15.0 такая возможность появилась, надо только выбрать 1 из этих 3 способов для директивы PARTITION_BY_REFERENCE в файле ora2pg.conf.

Адрес компании - HexaCluster.ai, и это неспроста: они, мол, специалисты по базам данных, но готовы помочь и в сооружении систем с искусственным интеллектом/машинным обучением. Как видно в том числе из статей вроде этой 2023: Year of Generative AI - о которой несколько слов ниже.

ora2pg 24.2

Жиль Дароль на днях выпустил эту версию, где как раз секционирование по ссылке.

Exploring JSONB in PostgreSQL

Статья адресована прежде всего тем, кто переходит с MongoDB на PostgreSQL, но и с Oracle на PostgreSQL и SQL Server на PostgreSQL.

Гаутам Банала (Goutham Banala, старший разработчик и админ больших кластеров) описывает некоторые полезные функции JSONB. Я бы обратил внимание на случай с правильным и неправильным GIN-индексированием при поиске по JSONB - полезный нюанс.

Образование

На сайте Postgres Professional опубликована электронная версия книги Владимира Комарова Путеводитель по базам данных. Книгу можно уже купить в бумажном виде.

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

Обновлена книжка-малышка.

Это уже 10-е издание книги Postgres: первое знакомство. Добавлена информация по новинкам 16-й версии PostgreSQL, появившимся возможностям работы с JSON, нашей работе с образовательными организациями (которой занимается Дарья Рисухина и ее коллеги), по новым продуктам компании, новым учебным курсам (PGPRO) и книгам («Мониторинг PostgreSQL» и «Путеводитель по базам данных»). Можно скачать в формате PDF.

И напоминаем о книге Алексея Лесовского Мониторинг PostgreSQL.

SQL query optimization: a comprehensive developer's guide

В блоге компании Aaiven нередко цитируемый нами автор - Франческо Тизьё ( Francesco Tisiot) - опубликовал довольно удобное руководство или даже памятку для начинающих. Да и продолжающих, пожалуй. Это советы по оптимизации, в каждом 4 рубрики: Как, Предупреждение, Золотое правило и Советы профи.

Советы образуют иерархию, разбиты по большим и малым темам:

• Оптимизация запросов SELECT

  • Понимание плана исполнения

  • Индексы

  • Оптимизация JOIN (используйте внутренние, используйте колонки с одинаковым типом, избегайте функций, вообще избегайте JOIN)

  • Оптимизируйте фильтры (избегайте функций)

  • Оптимизируйте подзапросы

  • Оптимизируйте вывод (paginate results)

  • Заменяйте фильтры HAVING на WHERE

  • Определяйте колонки (не используйте *)

  • Агрегаты

  • Оконные функции

  • Секционирование

  • Материализованные представления

• Оптимизация INSERT

  • Сужайте функциональность (dedicated functionality)

  • Ненужные индексы

  • Оптимизируйте INSERT как если бы это был SELECT

• Оптимизация DELETE

  • Ненужные индексы

  • Truncate

  • Секционирование

  • Разбивайте на куски

  • Вообще реже используйте DELETE

  • Совсем не используйте DELETE (например, создайте новую таблицу)

DBA1 на английском

Александр Мелешко перевел на английский курс DBA1-13. Исходный русский вариант: DBA1.

Конференции и митапы

Доклады на PGConf.Russia 2023 открыты для всех

- кроме случаев, когда докладчик специально оговорил запрет на публикацию.

PGConf.Russia 2024

Состоится 8-9 апреля. Регистрация открыта. Заявки на доклады уже не принимаются, программа ожидается 25 марта.

Extension Ecosystem Summit 2024

Об этом объявил в своём блоге со странным названием Just A Theory тот самый Дэвид Уилер (David E. Wheeler), которые основывал PGXN, а теперь весьма заметен в составе компании Tembo. Экосистемный саммит будет в рамках PGConf.dev в Ванкувере 28 мая. Дэвид надеется, что он будет ежегодным. А вообще планы у него грандиозные: The Jobs to be Done by the Ideal Postgres Extension Ecosystem.

О честных мультимастерах. Что (не) делать с высокодоступными кластерами

Мифы и реалии «Мультимастера» в архитектуре СУБД PostgreSQL. Части 1, 2 и 3.

Это серия статей, написанная Михаилом Жилиным (@mizhka) и Павлом Конотоповым (@kakoka) - сотрудниками компании Postgres Professional. Михаил занимается анализом производительности СУБД, Павел - архитектурой построения отказоустойчивых кластеров. У каждого более десяти лет опыта в своей области, они находили выход из катастрофических ситуаций, ловили ловко прятавшиеся причины проблем. Я знаю лично обоих как очень вдумчивых специалистов и статьи всячески рекомендую.

Там есть историческая часть - как развивалась технология «мультимастер» в экосистеме PostgreSQL, её внутренних механизмах, как и зачем её использовать. Особенно важно и интересно о Честном Мультимастере (список критериев) и об альтернативе мультимастеру - Черепахе: "если СУБД работает медленней черепахи, то это уже не база данных, а черепаха".

Спойлер: опенсорсные Traktor и pgEdge/spock, построенные на двунаправленной логической репликации 16-й версии PostgreSQL, нечестные. Но честные существуют, только они коммерческие: PGD (EnterpriseDB Postgres Distributed) у EnterpriseDB и расширение multimaster у Postgres Professional.

Далее обсуждаются гарантии согласованности данных; бесконфликтные типы (CRDT - Conflict-free Replicated Data Types, рекомендованная статья по теме - CRDT: Conflict-free Replicated Data Types); репликация изменений; способы разрешения конфликтов (Partner или Smart / CAMO (Commit At Most Once) / Eager Replication / Conflict triggers).

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

Итог такой:

• не про надёжность надежен;

• не про доступность уровень доступности может достигать 99,99*%;

• не для промышленного применения проверенное промышленное решение.

  Но всё ещё

• не про масштабирование записи, а про масштабирование чтения;

• не про пиковую производительность, а для нагруженных систем.

Михаил и Павел в своей статье ссылаются на доклад на HighLoad++ 2017 Ильи Космодемьянского (Data Egret), опровергаемый список как раз оттуда.

The Do's and Don'ts of Postgres High Availability

Part 1: Great Expectations

Part 2: Architecture Baseline

Part 3: Tools Rules

Это тоже 3-частная серия статей, на этот раз Шона Томаса (Shaun Thomas, EDB) , того, который ввёл в мир Postgres словечко phridays, подхваченное Райаном Бузом - о нём мы тоже не забыли, см. раздел Взрослые игры).

Там есть концептуальные вещи. Например, "все" слышали о CAP-теореме, а в HA есть похожая, расширенная теорема - PACELC. Смысл в том, что приходится выбирать в приоритеты либо малые задержи, либо согласованность. Но выбирать можно не вообще, а при определённых обстоятельствах - всё работает нормально -> думаем о задержках, что-то полетело в сети -> о согласованности. Между прочим, в вики en, в отличие от ru, приводится табличка с колонками P+A, P+C, E+L и E+C, где только у PostgreSQL галочки по всем 4 пунктам.

Соответственно, Шон во всех 3 частях использует аббревиатуры RPO (Recovery Point Objective) и RTO (Recovery Time Objective). И то и другое надо бы свести к минимуму, но одновременно быть здоровым и богатым не получается - и тут Шон от общих соображений переходит к средствам, инструментам и параметрам. Далее он поясняет логику переключений, а в конце рекомендует отказоустойчивые решения (никакой экзотики - Repmgr, Patroni, pg_auto_failover) и, конечно, родные ему EFM - EDB Failover Manager - и PGD, а также Barman и pgBackRest для бекапов.

Железный open source

Представлен первый процессор безопасности с открытым исходным кодом

Об этом Андрей Созинов пишет на 3dnews. Коалиция OpenTitan анонсировала первый коммерческий микропроцессор безопасности, построенный на одноимённой аппаратной платформе с открытым исходным кодом.

В чипе Earl Grey процессорное ядро на базе RISC-V и несколько встроенных аппаратных модулей безопасности и криптографии. Говорят, что это аппаратное воплощение принципа Керкгоффса: единственное, что должно быть секретным в криптосистеме, это сам секретный ключ. Партнер OpenTitan — Высшая техническая школа Цюриха. Благодаря участию академических кругов OpenTitan смог включить криптографические протоколы, которые безопасны для будущих квантовых компьютеров.

Статьи

Logging: What, Why and When

В блоге Генриэтты Домбровской (Henrietta 'Hettie' Dombrovskaya) статья об анализе логов начинается с того, что в Postgres около 30 параметров для отладки логирования, но обычно оставляют их значения по умолчанию. Почему? Да потому, что мало кто пользуется логами. Для мониторинга обычно используют внешние программы, которые будут скорее анализировать pg_stat_statements и другие системные таблицы и представления, чем логи.

Дальше в статье после подробного разъяснения, что будет происходить при этих дефолтных параметрах, речь пойдёт о pgBadger. Но Генриэтте удалось удивить читателя (вас - нет, так как дальше спойлер): вместо описания работы с этой утилитой, она рассказывает, как стала контрибьютором pgBadger, не написав ни строчки кода:

При всём обилии возможностей мне не хватало двух важнейших для меня:

1. анализировать логи так, как мне хочется (группировать, агрегировать и так далее) и

2. отслеживать сессии конкретных пользователей.

Проще говоря, нужен был способ загрузить все сырые данные pgBadger (расшифрованные, но не проанализированные логи) в базу. Так появилась новая опция: –dump-raw-csv. Пока процесс загрузки недостаточно автоматизирован. Как только будет - вы сразу узнаете от меня, - обнадёживает Генриэтта.

Эволюция системы разработки на SQL

"Команда Срочного рынка Московской Биржи (MOEX), занимаемся разработкой и сопровождением бэкофиса торгово-клиринговой системы Spectra" рассказывает о подопечных системах на MS SQL, но статья заинтересует, я думаю, и постгресистов. Тем более, что в Заключении сказано: а дальше нас ждет много увлекательных и интересных задач, связанных с переходом на другую СУБД. Что за СУБД? Загадка :) Но это путь будет в-третьих.

А во-первых, ведь пишут о системе электронной биржи, а это более 500 фьючерсных и 30000 опционных инструментов, несколько миллионов сделок в день.

Во-вторых, задачи там были нетипичные и интересные. Огромные усилия были потрачены на систему управления версиями. Сначала на базе SVN (Apache Subversion), а затем переходили на git, автоматизированную сборку, отчитывались о покрытии юнит-тестами и собирали билды в конвейере.

Особо важным справедливо считалось среда тестирования. В результате написали свой фреймворк на Python. Параллельно продолжался (и ещё не закончился) процесс декомпозиции монолита на модули.

Блокировки

pg-lock-tracer: A eBPF based lock tracer for the PostgreSQL database

Ян Ниджвецки (Jan Nidzwetski) предоставил набор инструментов для отслеживания блокировок:

• pg_lock_tracer - выслеживает блокировки на уровне таблиц PostgreSQL;

• pg_lw_lock_tracer - специализируется на LWLocks, используя USDT (Userland tatically Defined Tracing);

• pg_row_lock_tracer - следит за блокировками на уровне строки;

• animate_lock_graph - анимированные диаграммы, используя вывод pg_lock_tracer.

Ян использует технологии eBPF (Extended Berkeley Packet Filter). По сравнению с использованием pg_locks, теперь можно не только получить информацию по блокировкам в некоторый момент времени, а отслеживать их в реальном времени и строить анимированные диаграммы. Поддерживаются PostgreSQL 12, 13, 14, 15 и 16.

Взрослые игры

Changes to PGSQL Phriday Blogging Events

На 16-м месяце существования проекта Райан Буз (Ryan Booz) внёс изменения в правила своих знаменитых среди постгресистов PGSQL Phridays (о них наверняка знают постоянные читатели Postgresso, мы переводим Phridays как Пятнецы). Если что, правила есть на сайте, читайте.
Итак, отныне:

1. Этапы будут происходить не в первую пятницу месяца, а во вторую, а с темой надо определиться до 1-й.

2. Раньше обязательным условием участие была трансляция ответов каждого участника в Planet Postgres. Это лишнее, решил Райан, достаточного того, что идёт трансляция с его сайта. Но вот подведение итогов каждого этапа теперь строго обязательно. Впрочем, Райан обещает всяческую помощь участникам, если дела и обстоятельства затрудняют их пятнецы. Все 15 можно посмотреть по ссылкам с этой страницы.

What’s new in the Postgres 16 query planner / optimizer

Совсем взрослая игра. Или вообще не игра. Предлагаем интересный способ вдумчивого чтения: параллельно изучать статьи на пересекающиеся темы, желательно разноязычные. В данном случае статью Дэвида Роули (David Rowley, Citus) и статьи-обзоры Павла Лузанова о коммитфестах. По 16-й версии вот эти: ч.1 2022-07, ч.2 2022-09, ч.3 2022-11, ч.4 2023-01 и ч.5 2023-03. Польза не только в более глубоком понимании, но и в сращивании в собственном сознании английских и русских терминов - это не всегда тривиальная задача, а на все случаи постгрес-жизни словарик не составишь. Однозначное соответствие статей и терминов мы здесь, однако, не будем устанавливать, оставим это читателю.

Дэвид активный разработчик, его имя часто мелькает в переписке hackers сообщества. В статье он решил собрать новшества по части планировщика/оптимизатора в удобный список. Он и сам автор 6 из 10. По каждому из них не только дал пояснения, но и предложил свои SQL, чтобы читатель сам оценил разницу, всматриваясь в результаты EXPLAIN.

1. Инкрементальная сортировка в запросах с DISTINCT. Автор патча Дэвид Роули (Incremental sorts for DISTINCT queries).

   У Павла можно почитать об инкрементальной сортировке в ч.4: Новый параметр enable_presorted_aggregate (commit: 4a29eabd, 3226f472).

   Первый коммит уменьшает оценку стоимости инкрементальной сортировки. Теперь планировщик будет чаще выбирать этот метод сортировки. В том числе и для оптимизации агрегатных функций с ORDER BY и DISTINCT. Но в некоторых случаях неравномерного распределения данных в группах агрегаты с ORDER BY или DISTINCT будут проигрывать от использования инкрементальной сортировки.

2. Агрегаты теперь могут использовать предварительно отсортированные данные в запросах с ORDER BY или DISTINCT. Автор Дэвид Роули (Add the ability for aggregates having ORDER BY or DISTINCT to use pre-sorted data).

   У Павла в ч.4: Оптимизация группировки повторяющихся столбцов в GROUP BY и DISTINCT (commit: 1349d279)

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

3. Кеширование (мемоизация - memoize) в запросах с UNION ALL, Ришар Гуо (которого только что избрали в официальные коммитеры - Richard Guo, Allow memoize atop a UNION ALL).

   А вот здесь я бы порекомендовал и другое параллельное чтение: о мемоизации подробно написано в статье Егора Рогова Запросы в PostgreSQL: 5. Вложенный цикл.

4. Более гибкое исполнение анти-джойнов (JOIN с NOT EXISTS). Автор Ришар Гуо (Richard Guo, Allow anti-joins to be performed with the non-nullable input as the inner relation.

   У Павла: ищите в ч.5.

5. Распараллеливание FULL JOIN и INTERNAL HASH RIGHT JOIN. Авторы Мелани Плейгман и Томас Манро (Melanie Plageman, Thomas Munro, Allow parallelization of FULL and internal right OUTER hash joins).

   У Павла: ищите в ч.5.

6. Оконные функции теперь могут использовать режим ROWS, когда режим RANGE активен, но не необходим. Автор Дэвид Роули (Allow window functions to use faster ROWS mode when RANGE mode active but unnecessary)
   
   У Павла: ищите на этот раз в ч.4.

7. Оптимизация монотонно возрастающих оконных функций ntile(), cume_dist() and percent_rank(). Автор Дэвид Роули (Optimize always-increasing window functions ntile(), cume_dist() and percent_rank().

   Поищите сами, если ещё играете :)

8. Оптимизация, исключающая лишние соединения в LEFT JOIN и UNIQUE JOIN?? работает теперь и для секций. Автор Арне Ролан (Arne Roland, Allow left join removals and unique joins on partitioned tables).

9. Использование LIMIT вместо UNIQUE в предложениях с DISTINCT. Автор Дэвид Роули (Use Limit instead of Unique to implement DISTINCT, when possible).

10. Ослаблены слишком строгие правила в select_outer_pathkeys_for_merge(). Автор Дэвид Роули (Relax overly strict rules in select_outer_pathkeys_for_merge().

---

На этом пока всё.