SQL:2023
SQL:2023 is finished: Here is what’s new и
Postgres and SQL:2023: What's Supported?
Эти две статьи Питера Айзентраута (Peter Eisentraut) объединяем в одну. Во второй он только проставляет статусы и версии, в которых появилась поддержка. Статусов 3:
давно (ancient) - до версии PostreSQL 10;
не планируется - в том смысле, что и не стоит, поезд ушёл (по мнению Питера);
в будущем - хорошо бы сделать, но конкретно ничего не делается (по мнению Питера, и, кажется, не всегда он прав).
С момента выхода прошлого стандарта по шкале времени ИТ прошла Вечность: 7 лет с выхода SQL 2016. Дольше ждали только до 1999-го года - вообще-то тоже 7 лет, но Питер пишет, что дольше, он, наверное, влезал в детали. Не важно. Главное - долго, а в бездействии разработчикам ждать не дадут: клиенты просят новых фич, им не до стандартов.
Сейчас текст в Секретариате ISO - теперь только Боги ISO (как пишет Питер) определят дату официальной публикации. Это может занять от нескольких недель до нескольких месяцев.
Питер делит новости на три категории:
Небольшие изменения в существующем SQL.
Новое в JSON.
Новое в запросах к графам (property graph).
На мой взгляд эта тема достаточно важная, чтобы ей посвятить отдельную статью. Важная и для сообщества, и для тех, кто вкладывал немалые усилия в реализацию этих пунктов до выхода стандарта, то есть я прежде всего о многострадальных патчах SQL/JSON, которые обсуждались в том числе в наших выпусках: сначала ликование в Postgresso #3 (40), потом огорчение из-за отката обратно и осторожный оптимизм по поводу будущего в Postgresso 8-9 (45-46), а в Postgresso 10 (47) утешительная новость, что хотя бы в Postgres Pro Standard / Enterprise большая часть патчей приложена.
Не умаляя ценности статьи Питера, попробуем разобраться хотя бы с некоторыми пунктами, касающимися JSON:
JSON data type - эта фича, пишет Питер после ознакомления со стандартом, говорит не только о появлении самого типа, но и включает некоторый синтаксис, например JSON_SERIALIZE, JSON_SCALAR и IS JSON.
По этому поводу он замечает, что этот пункт стандарта вошёл ещё с версий 9.2/9.4. Но тут уместно, кажется, уточнить, что в ваниле действительно с давних пор есть этот тип, но не приведённые им самим выражения. А вот в Postgres Pro Standard/Enterprise 15 - да, они есть.
String-based JSON - пункт о том, как тип хранится, и реализация должна обеспечивать функциональность JSON_OBJECT, JSON_OBJECTAGG, JSON_TABLE и др. для традиционного текстового хранения, или для специфического (native), или для обоих вариантов.
Питер проставляет против этого пункта своё "не планируется", под которым, напоминаем, подразумевает, что и планировать больше не стоит. Это, он подчеркнул, его мнение.
Эта функциональность не попала тогда в PG 15, но обсуждалась она очень активно. И она тоже уже есть в Standard/Enterprise 15.
UPD: Только что пришла информация, что со второй попытки в 16-й версию попали функции-конструкторы (JSON_ARRAY, JSON_ARRAYAGG, JSON_OBJECT, JSON_OBJECTAGG) и предикаты (IS JSON [VALUE], IS JSON ARRAY, IS JSON OBJECT, IS JSON SCALAR) - подробнее в обзоре Павла Лузанова PostgreSQL 16: Часть 5 или Коммитфест 2023-03.
Вот вам и "не планируется".
Упомяну здесь и новую тему, не "близкую к телу":
Property Graph Queries - SQL/PGQ. Новый раздел, запросы как в графовой СУБД. Питер его маркировал как "в будущем", то есть желательный. Он ожидает, что это направление будет развиваться и в будущих выпусках стандарта. Как и JSON. Эти новшества суть движения в сторону NoSQL-функциональности. Но и в традиционном, "корневом" SQL тоже есть новое, но там, по словам Питера, либо уже реализовано, либо будет в PG 16.
Боги ISO обещают, вроде, сократить ожидание следующих стандартов до 3-4 года.
A Postgres JSONB Functions and Operators Cheatsheet
"Жульнический листок" переводится как шпаргалка. Но это не просто шпаргалка, это набор примеров, которые можно скопипастить, распробовав на небольшом демонстрационном наборе данных. Есть в виде PDF. Позаботилась о любителях шпаргалок фирма Aiven.
Блокировки
Если тема интересует всерьёз, то советуем сначала заглянуть в главу III книжки Егора Рогова PostgreSQL 15 изнутри или в его же соответствующую серию статей на хабре - Блокировки в PostgreSQL. А документация Postgres по этой теме лежит здесь.
Row locks in PostgreSQL
Лоренц Альбе (Laurenz Albe, Сybertec) решил разобраться с блокировками на уровне строки. Эта статья для тех, кто любит заглядывать под капот, как говорится.
Лоренц рассказывает об 4 подвидах блокировок и о том, какую когда лучше выбрать; о принципе эскалации блокировок (когда вместо большого количества отдельных строк сразу блокируется страница или таблица); как они хранятся. И в конце: в представление pg_locks блокировки не попадут, если конфликта не произошло, и мы не увидим, кто завладел блокировкой. Поэтому Лоренц предлагает расширение pgrowlocks, авторства Тацуо Ишии (Tatsuo Ishii). Теперь увидим их.
Postgres - Fun with LWLocks
Мишель Пакье (Michel Paquier) живёт в Японии, но сам из Франции, поэтому, хотя имя пишется как Майкл, как-то естественней предположить, что он Мишель (он докладывал на PGConf.Russia 2016, но пообщаться не довелось, поэтому не знаю, как он сам себя зовёт). Работает в AWS. Статьи его интересны и содержательны, не даром он коммитер Postges, и у него 12-е место по числу строк в новом Списке Вкладчиков, а по числу коммитов - так даже 5-е.
И эта статья тоже для заглядывателей под капот. И даже для любителей не заглядывать, а рыться там основательно. В менеджере легковесных блокировок в PostgreSQL есть API, который можно увидеть в src/include/storage/lwlock.h, который нужен для управления доступом к структурам в разделяемой памяти. Мишель рассматривает 3 из них:
LWLockUpdateVar()
LWLockWaitForVar()
LWLockReleaseClearVar()
Мишель не просто рассказывает о легковесных блокировках. Он ещё и сочинил небольшой модуль lwlock_test, который использует эти функции и умеет заставить 2 бэкенда перекидываться в пинг-понг так, что каждый будет ждать от другого, когда тот обновит переменную. Можно скомпилировать модуль с флагом DLWLOCK_TEST_DEBUG. Тогда в логе будут появляться записи каждый раз, когда происходит событие в ожидающем или обновляющем процессах.
Нескромно посоветую интересующимся и вот эту нашу с Александром Коротковым (ныне в Oriole DB) статью Параллелизм в PostgreSQL: не сферический, не конь, не в вакууме. Там тоже under the hood, тоже pg_locks и LWLocks, но ещё и на материалах конкретной случившийся проблемы. Да ещё и с советами по perf и GDB.
А любимый жанр Мишеля Пакье - PostgreSQL * highlights. Здесь дадим набор ссылок на его заметки по
PostgreSQL 16:
require_auth for libpq
Control of SCRAM iterations
File inclusions in pg_hba.conf and pg_ident.conf
More patterns for pg_ident.conf
Normalization of utilities in pg_stat_statements
More regexps in pg_hba.conf
Ну и тогда уж, чтобы не обделить Павло Голуба (Pavlo Golub, Cybertec):
LZ4 and ZSTD pg_dump compression
Underscores in numeric constants
Parallel aggregate
New old "debug_parallel_query" setting
Reserve connections
hex, oct, bin integers
pg_dump compression specifications
GRANT VACUUM, ANALYZE
Лоренц Альбе (Laurenz Albe) тоже работает в Cybertec. У него тоже есть статья по PostgreSQL 16:
EXPLAIN (GENERIC_PLAN): New in PostgreSQL 16
Ну а у Депеша Любашевского все ожидания PostgreSQL 16 собраны, как обычно, под одноименной рубрикой.
А теперь главное, может быть, в этом разделе обзора: только что опубликована 5-я часть коммитфестовских обзоров Павла Лузанова. Вот все 5:
PostgreSQL 16: Часть 5 или CommitFest 2023-01 (ru), (en ещё не готов);
Ч. 4, 2023-01 (ru), (en);
Ч. 3, 2022-11 (ru), (en);
Ч. 2, 2022-09 (ru), (en);
Ч. 1, 2022-07 (ru), (en).
Five Interesting Patches From January’s Commitfest
Крис Трейверс (Chris Travers), тот самый иностранец, лично приехавший на недавний PGConf.Russia 2023, продолжает свою прошлогоднюю затею: обозревает коммитфесты и, отдадим должное, вовсе не повторяет Павла Лузанова. Во-первых, он по-прежнему обозревает не только принятые патчи (в данном случае их 3), но и отложенные (1) и даже отвергнутые (1). Он ещё и следует придуманной им форме: в сообщении о каждом патче кроме описания есть раздельчик Почему это важно.
По поводу небольшого патча он рассказывает любопытную историю о том, как в Postgres появлялись -infinity и +infinity, почему просто infinity не всегда хватает. Патч приняли. А вот этот набор патчей самоустранился из-за возникших проблем, но это не значит (показывает Крис), что работа была проделана напрасно. Ну а вот этот набор нам ближе к телу: Крис говорит о многолетней деятельности Postgres Professional по продвижению 64-разрядных xid. Эти патчи, говорит Крис, когда-то опередили время, зато теперь стали как никогда актуальны. И Timescale, где Крис теперь работает, включилась в доработку и продвижение этих важнейших патчей.
Напоминаем, что в конце марта определилась PostgreSQL 16 Release Management Team:
Альваро Эррара (Alvaro Herrera, EDB);
Амит Капила (Amit Kapila, Fujitsu India);
Джонатан Кац (Jonathan Katz, AWS).
Бонус: v. 15
ICU features in PostgreSQL 15
Питер Айзентраут (Peter Eisentraut, EDB) делится плодами своих усилий (он одновременно и автор, и коммитер патча) по доведению поддержки правил сортировки (collation) ICU до ума. Поддержка библиотеки ICU появилась в PostgreSQL 10, но её нельзя было использовать глобально для базы данных или всего кластера баз данных. Питер рассказывает не только о сделанном, но и о не сделанном - что сделать надо. И, видимо, будет сделано в скором времени.
Конечно, я заглянул сначала в PostgreSQL 15: Часть 5 или Коммитфест 2022-03, где сказано ещё и о информативных столбцах datlocprovider, daticulocale в pg_database, о которых Питер умалчивает. Умалчивает и в другой статье - How collation works, поясняющей работу правил сортировки, что ничуть не говорит о том, что статья не достойна чтения.
Питер не только рассказывает о сортировке, не только отсылает к стандартам, а ещё и разбирает по косточкам сами записи, связанные с символами UNICODE, заныривая в первоисточники - файлы DUCET и Implementation_Notes, рассказывает, зачем у символов веса и как они работают. Но ещё больше интересного обещает рассказать на эту тему в будущих статьях.
Вклады и круги
The Importance of Giving Back: Analyzing Code Contributions to PostgreSQL 15
Сара Конвей (Sarah Conway) из EDB опубликовала заметку о вкладах компаний в PostgreSQL 15, оформив результаты в красивую диаграмму-пирожок (не воспроизводим, соблюдая копирайт). EDB - лидер по вкладам. 2-е место уверенно держит Postgres Professional, третье у Fujitsu. Crunchy Data - 6-е (я думал, что выше), китайская HighGo - уже 11-е, а за ним юный и модный Neon, а Ajust - на 14-м. Я, конечно, обращаю внимание на те компании, чьи статьи мы часто цитируем. Подальше расположились Arenadata, Bank of China, Data Egret, EPAM Systems, в хвосте затаились IBM, HP и Intel. Пирожок выпекался на основе имён "вкладчиков", упомянутых в release notes, их привязывали к компаниям и смотрели статистику. Также смотрели список contributors/committers. То есть, если много участников процесса (что, безусловно, важный критерий) внесли понемногу кода, компания опередит ту, в которой есть 1, но экстремально плодовитый. Хаас (ниже), наоборот, считает только строки кода, поэтому картина совсем другая. В идеале испечь бы гибридный пирожок, посчитав суммы строк кода для упомянутых вкладчиков.
Заметка, вообще-то, о том, как выбрать поставщика Postgres-СУБД. Сара предлагает такие критерии:
поддерживает ли компания своих сотрудников, предлагающих сообществу код или другую помощь?
есть ли у компании внятно прописанная политика в отношении открытого кода?
как обстоят дела с компанейскими блогами, вебинарами, подкастами, документацией?
И отвечает: да, наша EDB, она такая.
Robert Haas: Who Contributed to PostgreSQL Development in 2022?
Роберт Хаас (Robert Haas) в своём блоге недавно дал очередную статистику вкладов - за 2022 на этот раз. 2021 и 2020 здесь. Традиционно там списки лидеров по числу строк кода, коммитеров и самых активных в рассылках - не компаний, а разработчиков лично. Первая пятёрка по вкладу в строчках:
Том Лейн (Tom Lane) 36623 строк в 356 коммитах; а в 2021 было 66210 | 438
Андрес Фройнд (Andres Freund) 34140 | 207 - приблизился!
Питер Айзентраут (Peter Eisentraut) 18697 | 263
Брюс Момджан (Bruce Momjian) 9677 | 61
Томас Вондра (Tomas Vondra) 9438 | 23
СУБД-круг Громова 2022 - исследование русских СУБД-вендоров, российское ПО базы данных
В Кругах Громова появился огромный (более 400 стр. PDF) обзор СУБД на российском рынке. Его можно получить, запросив на сайте. Из здешних постгресовых обозреваются:
Postgres Pro,
Jatoba,
Platform V Pangolin,
Tantor,
Квант-Гибрид,
Astra Linux Special Edition СУБД.
Но есть там ещё рубрика Российские:
Ред База Данных,
ЛИНТЕР,
CronosPRO,
Енисей.
Это исследование обсуждается, например, на IT Channel News:
Кто есть кто на российском рынке СУБД?
На том же ресурсе цитируют подсчёты Натальи Касперской: % СУБД в ЕИС «Госзакупки»:
На рынке СУБД произошла смена лидера продаж
А именно:
В денежном выражении в 2022 г. затраты госкомпаний на приобретение российских СУБД, выросли, по сравнению с 2021 г., почти в три раза: c 690 млн. до более чем 2 млрд. руб».
Интересно отметить, что 89% этой суммы пришлось на СУБД Postgres Pro. Далее с большим отрывом следуют Arenadata (4%), Oracle (2%) и «Ред База данных» (2%). Для сравнения: 2021 г. на долю Oracle приходилось 84% продаж.
Конференции
PgConf Nepal 2023
Пройдёт уже 11-12-го мая в Университете Катмаду. Первая тройка организаторов:
Dr. Oleg Bartunov - Postgres Professional, Russia
Mr. Andreas Scherbaum - European PostgreSQL
Dr. Bal Krishna Bal - Kathmandu University
Расписание ещё (на 3-е мая) не опубликовано, есть график мастерклассов. Известно, что участвуют Олег Бартунов, Егор Рогов и Павел Толмачёв (оба - коллеги из отдела образования), Александр Бурцев (все 4 из Postgres Professional), а также Крис Трейверс (Chris Travers, Timescale), Умайр Шахид (Umair Shahid, Percona) и много незнакомых мне фамилий, звучащих по-индийски.
На конференции будет представлен только что отпечатанный перевод Малютки. В качестве afterparty - восхождения и высокогорные марафоны.
PGIbiza 2023: Postgres and Ecosystem
Тоже неплохое место. После 4-летнего перерыва (виноват, говорят, ковид) пройдёт на острове 29-31-го августа. Скоро будут принимать заявки. Организатор - Fundación PostgreSQL - испаноговорящий постгресовый фонд.
PGDay Belgium 2023
PostgreSQL Database Conference состоится 12-го мая в Лёвен (Leuven) - Хаарсроде (Haasrode), 25 км. от Брюсселя. Регистрация продолжается, есть список выступающих и расписание.
Saint Highload++
Пройдёт в Санкт-Петербурге 26-27-го июня. Уже доступно расписание. Там есть, например, такие доклады:
Современные транзакционные базы данных. Как выбрать СУБД в 2023? Куда все движутся? - Олег Бондарь (Яндекс). Но движется, видимо, не совсем туда, куда бы нам с вами хотелось: обсуждаться там будет не Postgres, а TiDB, CockroachDB, YugabyteDB, YDB и SPQR.
Эндогенные угрозы физической целостности СУБД - Андрей Бородин (Yandex Cloud).
Страничка тематики баз данных здесь, она, видимо, будет обновляться.
HighLoad++ 2023
Московский Highload++ пройдёт в ноябре, даты пока не объявлены. Есть страничка, где все конференции Олега Бунина.
PGConf.Russia 2023
Уже прошла. Вот наша статья о ней: PGConf.Russia 2023: это было красиво. Почти все слайды и видео уже доступны участникам (после регистрации в личном кабинете).
Гео
PgOSM Flex for Production OpenStreetMap data
В блоге RustProof Labs Райан Ламберт (Ryan Lambert) рассказывают об инструменте PgOSM Flex, который помогает загружать в PostGIS данные OpenStreetMap, используя osm2pgsql. И приводит несколько примеров загрузки OpenStreetMap.
Особенно любопытно было листать эту статью, посетив до этого доклад Игоря Сухорукова Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap на PGConf.Russia 2023.
Брайан, кстати, напоминает, что доступна его книжка Mastering PostGIS and OpenStreetMap.
European Route Planning with Postgres
Марк Литвинчик (Mark Litwintschik) берёт маршруты автобусов по Европе и с помощью расширения pgRouting планирует маршруты. Полезный и интересный опыт.
Postgres Raster Query Basics
Пол Рэмзи (Paul Ramsey) рассказывает о том, как хранятся растровые данные, как можно организовывать запросы к таким данным из PostGIS.
Shoot yourself
The Part of PostgreSQL We Hate the Most
Автор - профессор Карнеги Меллона Энди Павло (Andy Pavlo) из компании OtterTune. Классик начинает с классики: как появлялась и продвигалась концепция MVCC, а доходит до того, что реализация этого MVCC в PostgreSQL худшая (он именно буквально подчёркивает это) из ряда MySQL, Oracle и Microsoft SQL Server. Но мы тут, в OtterTune, вам с этим поможем, и вашим RDS или Aurora теперь особенно ничего угрожать не будет - говорит Энди.
Он ссылается на "лучшую статью времён и народов по MVCC" 2018-го года - An Empirical Evaluation of In-Memory Multi-Version Concurrency Control - своего коллектива, он вспоминает о захиревшей попытке zheap project, он наступает на больную мозоль - случай Uber, и, разумеется, препарирует работу автовакуума. В статье много наглядных схем и графиков. И, между прочим, уличает писателей с Uber в существенной ошибке (даёт ссылку, но она никуда не ведёт). Заодно рекламирует Database of Databases, в которой на сегодня 897 баз. Короче, это интересно.
Nine ways to shoot yourself in the foot with PostgreSQL
Фил Бут (Pfil Booth) делится в своём блоге собственными неудачами в эксплуатации рабочих баз, советует разобраться в этих 9 вопросах сразу, до того как база вырастет и выстрелит в ногу. Ничего особенно сенсационного нет, начинается всё с настройки work_mem. Видали мы и более основательные разборы этой реально важно темы, а Кристоф Петтус (Christophe Pettus) вообще заявил здесь, что ВСЕ формулы для work_mem лгут (мы его бегло обозревали в Postgresso 3 за 2023).
Но здесь интересен, скорее, список выстрелов, чем конкретные советы. На хабре есть русский перевод - Девять способов выстрелить себе в ногу с PostgreSQL - переводчика Вадима Иншева aka PatientZero, но я позволю себе некоторую вкусовщину и дам свою версию выстрелов:
оставьте как есть work_mem по умолчанию;
затолкайте всю логику в функции и процедуры Postgres;
навесьте кучу триггеров;
увлекайтесь NOTIFY;
НЕ запрашивайте EXPLAIN ANALYZE на реальных данных;
предпочитайте CTI подзапросам;
в критичных по времени исполнения запросах используйте рекурсивные CTI;
не создавайте индексов на внешних ключах;
сравнивайте индексированные столбцы, используя предикат IS NOT DISTINCT FROM.
ORDINALITY и перекосы
Easy PostgreSQL Time Bins
Пол Рэмзи (Paul Ramsey, Crunchy Data) пишет о том, как эффективно управляться с временнЫми данными. Для иллюстрации он берёт геоданные землетрясений и пользуется PostGIS. Землетрясения (крупные) случаются не каждый день, поэтому гистограммы и разные диаграммы могут получиться некрасивыми, если не учитывать временнУю разряженность.
Пол показывает, как работает появившаяся в PostgreSQL функция date_bin(). Её он использует в вместе с generate_series().
В другой раз он использует функции width_bucket(), unnest() и запрос с довольно экзотичным ключевым словом WITH ORDINALITY.
Maximizing PostgreSQL’s Charms: A Pattern for Indexes and Skewness When Migrating from Oracle
Дипак Махто (Deepak Mahto) выбрал не затасканную тему: перекос данных при миграции. Он предлагает в этом случае пользоваться частичными индексами (partial indexes).
Старый добрый psql
PostgreSQL Basics: Getting started with psql
Райан Буз (Ryan Booz, Redgate), знакомый по PGSQL PHRIDAYs (на этот раз отдохнём от них), агитирует за psql. Читатели это обзора вряд ли нуждаются в такой агитации, но в статье есть любопытная табличка истории psql, начавшейся в 1970-м. Кому-то может пригодиться советы по инсталляции Postgres на Мак, кому-то - в докере.
Некоторые релизы
openGauss 5.0.0
Честно говоря, об openGauss я узнал на PGConf.Russia 2023 из доклада Максима Милютина Аналитические open-source решения на базе PostgreSQL. Эту постгресовую СУБД разрабатывает Huawei, и она показывает неплохие результаты на их чипах kunpeng на базе ARM. В 2021-м появилась 1.0.1, а сейчас уже 5.0.0. Вот правильная (!) ссылка на страницу Release Notes. Распространяется по лицензии Mulan PSL v2.
dbdev: A Postgres Package Manager
Разработчики из Supabase представили database.dev - сайт, на котором можно найти расширения на доверенных языках Postgres. Создатели говорят оdbdev:это для PostgreSQL то же, что pm для JavaScript, pip для Python иcargo для Rust. А вообще цель их создать open ecosystem для работы с пакетами.
На сегодня всё.
