Postgresso #6 (91)

Бета 2 вышла ^[1], в ней 14 исправлений, если считать за 1 исправление целый набор поправок к SQL/PGQ property graph ^[2]. Понемногу выходят статьи о достижениях 19-й версии.

pgrust это СУБД или злая шутка?

Майкл Мэйлис (Michael Malis), житель Сан Франциско, основатель freshpaint‑io ^[3], работал в компании Heap ^[4] — человек в мире Postgres не слишком известный, хотя давний пользователь. Он, скорее, из мира фанатов Rust ^[5] и Common LISP. Он был бы возмутителем спокойствия Postgres‑сообщества — да чего там: ИТ‑сообщества — если б там сейчас было какое‑то спокойствие.

У него есть свой сайт — malisper.me ^[6]. Там многое рассказано, хотя наиболее шустро новость разошлась с форумов — с рэддит: pgrust: Postgres rewritten from scratch in Rust, currently passing 34% of the Postgres test suite ^[7], или с ycombinator ^[8]: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests ^[9]. В рунете новость появилась на OpenNET.ru ^[10]: pgrust — клон PostgreSQL на Rust, проходящий все регрессионные тесты ^[10].

На сайте Майкл публикует новости своего проекта. Обратите внимание ^[11] на тайминг:

• 20 апреля: pgrust: Rebuilding Postgres in Rust with AI ^[12]: 2 недели назад [=6 апреля] я [в смысле Майкл] начал этот проект. Сейчас [20-го] в нём 450К строк кода.

• 28 апреля: pgrust update: at 67% Postgres compatibility, and accelerating ^[13].

• 26 мая: О четырёх всадниках апокалипсиса, 96% тестов: The four horsemen behind thousands of Postgres outages

• 25 июня: pgrust passes 100% of the Postgres regression tests ^[14].

• 16 июля: Три тупика: Postgres in Rust: three dead ends before we passed 100% of the regression suite ^[15].

Сразу приведём здесь ресурсы самого Майкла:

• Попробовать можно на pgrust.com ^[16] (WASM‑демо в браузере).

• GitHub ^[9].

• Туса на Discord ^[17].

• Есть и mailing list ^[18].

Переписывал он на Rust не один. Во‑первых, вместе с Opus, щедро заплатив ему $100k. Ещё и транслятор c2rust ^[19] использовали. Но Майкл и сам не ленив: он участвует в AoC (Advent of Code ^[20]), мы об этом писали в номере Postgresso № 6 (55) ^[21].

Кроме того он делал проект ещё и вместе с вполне кожаным другом — Джейсоном Зайбелем (Jason Seibel).

Им мало просто переписать весь Postgres для спортивного интереса ^[22]. Они искренне хотят его улучшить.

В статье о Всадниках Апокалипсиса Майкл ругается на:

1. Вакуум и Wraparound — это понятно, все ругаются. Майкл думает начать с 64-битных Xid и задумывается о других TAM (Table Access Methods — о том, что с ними творится последнее время, мы писали в Postgresso #5).

2. Маловато соединений держит, и слабый параллелизм в исполнении запросов. Майкл вместе с Rust переходит на треды вместо процессов.

3. Плохие планы запросов — обычно Postgres выбирает правильные алгоритмы, но если ошибается, то ошибается ооочень сильно — считает Майкл. Он собирается научить pgrest разумно действовать в таких случаях.

4. Это, на мой вкус ^[23], самый неожиданный пункт: JSON. Что с ними‑то не так? По ним нет нормальной статистики, считает Майкл. И даже приводит статью своего бывшего коллеги по Heap: When To Avoid JSONb In A Postgresql Schema ^[24]

Postgres только что (8 июля) отпраздновал 30-летие (см. ниже в нашем обзоре). За это время в него вложили столько человеко‑часов, что против pgrust это Вечность против мгновения. Можно понять ярость ^[25] и даже бешенство некоторых комментаторов в форумах, их ругань.

Никто в здравом уме не запустит такую штуку в прод. Но автор и не претендует (пока) на это.

Можно спросить себя и других: и чего стоят эти многочисленные регрессионные тесты, если ИИ‑поделка их проходит играючи? Достаточно ли глубоко копают тестировщики?

Можно присвистнуть, покачать головой и задумчиво произнести: «это только начало». И оказывается, что в форумах уже кое‑что нашли:  We’re building Postgres in Rust. Using the LLVM of databases ^[26]. Мы — это компания Turso ^[27] (до этого они переписали на Rust SQLite). Но может через пару лет таких проектов будет 100, а форки будут ветвиться тысячами? И это будет хаос? Или это будет экспериментальная площадка нового поколения, и всё это на пользу Постгресу и Прогрессу?

Итак: процессы vs. треды

В сообществе на тредах отнюдь не поставили крест. Тредов пока нет, но их не только обсуждают, но и делают понемногу. Хотя в их необходимости сомневаются авторитетные люди. Сначала немного ликбеза:

Processes and Threads ^[28]

Бен Дикен (Ben Dicken) из PlanetScale ^[29] объясняет в корпоративном блоге ^[30] разницу между процессами и потоками (тредами) очень наглядно и с низкого уровня: с нулей и единичек. Он приводит Postgres как удачный пример СУБД на процессах, а MySQL — как удачный пример СУБД на потоках. В PlanetScale ^[29] исторически занимались MySQL и Vitess, но последнее время торжественно заявляли о претензиях на место под солнцем Postgres. Летом они заявили о готовности: PlanetScale for Postgres is now GA ^[31].

Нам легче всего отследить некоторые ходы полемики по собственным публикациям — они не всё охватывают, но картину дают.

Ещё в ноябрьском номере за 2020 — Postgresso 26  ^[32]— тема затрагивается, хотя и косвенно в контексте описания интересов нового члена Core Team Андреса Фройнда (производительность, масштабируемость и хранение). Там дается интригующая отсылка: «треды, а не процессы? Спойлер Андреса: если аккуратно померить, то…» (с отсылкой к его исследованиям накладных расходов процессной модели): Measuring the Memory Overhead of a Postgres Connection ^[33]. Речь о серии из 3 статей о производительности PostgreSQL при большом числе соединений.

Статья об издержках памяти ^[34] начинается с популярного мотива — а если бы треды, а не процессы? Спойлер Андреса: если аккуратно померить, то издержки меньше 2 мебибайтов ^[35]. А неаккуратно — это при помощи top и ps.

Для более тонких замеров памяти Андрес использует системные /proc/$pid/status и /proc/$pid/smaps_rollup. Так можно увидеть значения VmRSS, VmRSS, RssAnon, RssFile, RssShmem — если вы не знали, что это, то из статьи узнаете и поймёте, почему они важны. Чтобы не обмануться с причиной перерасхода памяти, он замеряет с включенным и отключенным huge_pages. Ещё: надо помнить о copy‑on‑write ^[36] при форке процесса.

В июльском номере за 2023 — Postgresso № 6 (55) ^[21] — была целая секция на эту тему. Обильно процитируем — для удобства:

Новый виток старой дискуссии. Джонатан Корбет (Jonathan Corbet) решил обобщить дискуссию в рассылке.

В июне Хейкки Линнакангас (Heikki Linnakangas, теперь мы его знаем как сооснователя Neon) предложил начинать переделку всей модели Postgres с процессов на потоки (треды):

Я обсуждал этот вопрос на конференции PGCon и у меня впечатление ^[37], что сейчас сложился мощный консенсус, более серьёзный, чем до этого. Проблем много, но, что это в принципе надо делать, возражений я не слышал. Поэтому сейчас озвучиваю этот консенсус. Высказывайтесь.

Там же он предложил краткий перечень задач. Понятно, что за один релиз не перейти на треды. Андрес Фройнд (Andres Freund) поддержал ^[38]:

Мы начали упираться в целый ряд ограничений процессной модели, особенно на больших машинах.

«За» высказался ^[39] и Роберт Хаас (Robert Haas, EDB):

PostgreSQL плохо масштабируется на больших системах, в основном из‑за потребления ресурсов этими процессами. Такая проблема не у всех СУБД, и Postgres не изменить в этом отношении без кардинальных архитектурных изменений. Для этого даже перехода с процессов на треды будет недостаточно. Но это подтолкнуло бы к другим изменениям.

Не смотря на поддержку таких авторитетных людей, заявление Хейкки не подтвердилось. Достаточно ответа ^[40] Тома Лейна (Tom Lane, Crunchy Data), остающегося самым продуктивным ^[41] разработчиком Postgres, чтобы констатировать: мощного консенсуса нет:

Я думаю, что это будет катастрофа. Огромное количество кода будет в результате поломано.

С самого начала этой дискуссии вспоминали, что в 2017-м Константин Книжник (тогда в Postgres Professional, потом в Neon) экспериментировал ^[42] с потоками. Сам он сказал, что это оказалось проще, чем он думал. Но с тех пор он не продолжал этим заниматься.

Автор заканчивает статью так: цельтесь в звёзды, попадёте на Луну. Если цели нет, то и останетесь в Нигде.

Для LWN.net ^[43] Джонатан написал ещё одну (как минимум) статью в том же жанре: PostgreSQL’s fsync() surprise ^[44]. Тоже с большими и многими ветками комментариев. Она написана ещё в 2017-м.

И на конференциях, на самых ключевых, нередко эту тему обсуждали:

Postgresso 3–4 за 2025 (76–77) ^[45] В обзоре конференции pgconf.dev ^[46] 2025 отмечалось, что тема многопоточности остается актуальной на самом высоком уровне. Упоминались два профильных доклада:

• «Investigating Multithreaded PostgreSQL» — Томас Мунро (Thomas Munro).

• «Multithreaded PostgreSQL (2025 edition)» — Питер Айзентраут (Peter Eisentraut).

И так далее.

PG‑wiki есть страничка Multithreading ^[47]. Там есть в том числе список ресурсов на тему:

• обсуждение в рассылке pgsql‑hackers ^[48],

• презентация ^[49] на PGConf.eu ^[50],

• текущая разработка на гите ^[51],

• патчи ^[52].

Итак: вакуум. И MultiXact

Сейчас об отмене вакуума говорят уже ссылаясь на произведение Александра Короткова (Alexander Korotkov) OrioleDB ^[53] — самое doable, как говорят англоязычные (о новых методах доступа почитайте в прошлом номере — Postgresso #5 (90) ^[54] — и статье Table Access Methods Wake Up ^[55] Кристофа Питтуса (Christophe Pettus). И напоминаем, что по словам Пола Коплстоуна (Paul Copplestone, гендир и сооснователь компании) OrioleDB должна достичь уровня продакшн уже в этом году.

Potential Consequences of Using Postgres as a Job Queue ^[56]

Эту статью Ричард Йен (Richard Yen ^[57]) опубликовал в собственном блоге ^[58], но оригинал ^[59], он говорит, на Microsoft Community Hub ^[59]. Излагает он чётко. Проблемы:

• MultiXact SLRU,

• раздувание (распухание, разрастание — короче: bloat),

• CPU и издержки блокировок (lock overhead).

Как бороться:

• постгресовые средства: Advisory Locks,

• pgq (Skytools),

• PgQue ^[60] — Николай Самохвалов (Nikolay Samokhvalov) допилил pgq,

• Redis,

• Kafka.

Тема MultiXact не даёт ему покоя: есть ещё его статья:

XID Wraparound’s Equally‑Evil Twin ^[61] — то есть зловредный близнец: MultiXact ID wraparound. Дальше, правда, Ричард противоречит сам себе, называя близнеца двоюродным братом (there’s a quieter, less‑discussed cousin). Но более странно другое: он ни словом не упоминает важное новшество Postgres 19: 64-разрядные структуры MultiXactOffset и MultiXactMembers (автор Максим Орлов — Maxim Orlov, ревьюер — Хейкки Линнекангас — Heikki Linnakangas).

Ричард легко и просто пишет на интересные темы. Вот, например:

The Postgres Performance Triangle ^[62]

Постановка вопроса немного напоминает CAP‑теорему ^[63]: помни о всех 3 вершинах треугольника:

• Память (Memory Allocation).

• Производительность диска (Disk I/O).

• Конкурентность (Concurrency).

И отдадим должное: по теме PgQue, например, Ричард рекомендует статью Кристофа Питтуса (Christophe Pettus ^[64], PGX ^[65]) в блоге The Build ^[66] – как более технологичную:

PgQue: Two Snapshots and a Diff ^[67].

Из неё мы узнаём, что проект представляет собой порт PgQ — движка очередей эпохи Skype образца 2007 года, переписанный на чистый SQL и PL/pgSQL. Базовый алгоритм остался в точности таким же, как в оригинальной версии Марко Крина (Marko Kreen).

Что особенно интересно — пишет Кристоф: этот алгоритм незнаком целому поколению разработчиков PostgreSQL, которые привыкли организовывать очереди исключительно с помощью SKIP LOCKED. И он оказывается куда более элегантным, чем они могли бы предположить.

Кристоф Питтус пишет и о MultiXact*:

MultiXact Members at 64 Bits: One Less Wraparound to Worry About ^[68]

И в статье есть важный раздел: что сломалось.

В целом The Build ^[66] стал с некоторых пор выглядеть странно: статьи на разные темы — обычно интересные и технологичные — потонули в полноводном потоке, в бесконечном сериале All your GUCs in a row.

Приведу здесь слова Павла Лузанова (руководителя нашего отдела образования, напоминаем об его обзорах коммитфестов ^[69]):

В постгресе 402 конфинурационных параметра (в 19-й версии). Кристоф взялся за большой труд: описать каждый параметр. И идет по алфавитному порядку. gin_fuzzy_search_limit – 131-й, так что впереди еще много. Это не первая попытка сделать описание конфигурационных параметров.

Есть еще вот такой сайт: https://postgresqlco.nf/ ^[70] Но этот сайт скорее удобен тем, что можно найти быстро, что в какой версии появилось, описание из документации и ссылки на SO. А Кристоф прямо вкладывается в предназначение каждого параметра, зачем он нужен и почему.

Всё‑таки задержусь ещё на Бильде: The Maintainer Is Not the Owner ^[71] — вот интересная тема, становящаяся — опять же — более актуальной.

Ну а пока автовакуум не отменили, вот статья Лауренца Альбе (Laurenz Albe). Как всегда серьёзная, с листингами:

Monitor autovacuum: the queries I prefer ^[72] — в статье и о рэпараунде, и о раздуваниях‑распуханиях, и о заморозке, и о записях‑мертвяках. То есть — о главном.

В ИИ‑контексте

Сейчас, вообще‑то, вся ИТ‑отрасль в контексте ИИ. Отсюда нервозность, которую подкрепляют главные фигуры. Главней фигуру, чем Папа Римский Лев XIV (он же Роберт Фрэнсис Прево), трудно придумать, а он придумал (со своими консультантами, конечно) ИИ‑Энциклику Magnifica humanitas (Великолепное человечество). Сотни страниц, сотни пунктов. Вышла 15 мая 2026 года по случаю 135-летия социальной энциклики Rerum novarum) выпустил свое первое программное послание, полностью посвященное искусственному интеллекту ^[73] Pope Leo’s “Magnifica humanitas”: AI must serve humanity not concentrate power — Vatican News ^[74]

В Ватикане по этому поводу выступил атеист Кристофер Олах (Christopher Olah), сооснователь Anthropic. Об этом рассказывает Гардиан в The Guardian view on the Pope and Claude: Leo XIV’s encyclical on AI is right to put humanity first ^[75]. Навёл на этот сюжет Павел Конотопов, спасибо.

Кратко — здесь: Энциклика Льва XIV: ИИ на службе человечеству, а не горстке властителей ^[76] — тоже на официальной странице Vatican News ^[76].

Сообщество ревностно следит и за высказываниями Линуса Торвальдса. Он — даже говорят некоторые — «переобулся ^[77]». Но, вроде, вполне плавно подкорректировал свою позицию по поводу ИИ. Ещё вот здесь, в Why Linux creator Linus Torvalds gets angry hearing “99% of code is AI” ^[78] на The New Stack ^[78], он остроумно высказался:

Меня натурально бесит, когда люди говорят: «99% нашего кода написано ИИ». А я могу гарантировать: 100% их кода написано компиляторами. Но об этом они помалкивают.

Он подчеркнул там 2 вещи:

1. ИИ — не творец, а инструмент в руках человека‑творца.

2. Социальная роль проекта важна, но она лишь побочный эффект, а не цель. Мы тут не воины света (social warrior). Проект таким никогда не был и никогда не будет.

Вот его слова буквально:

Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that’s a side benefit, not the point of the project. This is NOT some kind of “social warrior” project, never has been, and never will be.

Social (Justice) Warrior ^[79] — это не слишком почтительный мем в адрес ультра‑активистской деятельности в англоязычном контексте. Так что это почти политическое высказывание.

Сэм Альтман вообще объявил: сингулярность не то что «при дверех», оно уже с нами. Это в подкасте Relentless 25 июля. Но следует просмотреть хотя бы по диагонали его манифест годовалой давности в собственном блоге ^[80]: The Gentle Singularity ^[81].

<…>, это не <…> ИИ‑система, которая полностью автономно обновляет собственный код, но тем не менее это зародышевая форма рекурсивного самосовершенствования«.»

И там ещё есть про рекурсию. Есть и про высокопроизводительные BCI (brain‑computer interfaces), и даже про энергетическую стоимость 1 запроса:

Людей часто интересует, сколько энергии тратит запрос к ChatGPT; в среднем один запрос расходует около 0,34 ватт‑часа — примерно столько же, сколько духовка за чуть больше одной секунды, или энергосберегающая лампа за пару минут. Кроме того, на него уходит около 0,000085 галлона воды — примерно одна пятнадцатая чайной ложки.

Но самое интересное, как мне кажется, это его видение стартапов будущего:

Долгое время технические специалисты в стартап‑индустрии посмеивались над «людьми с идеями» — теми, у кого была только идея, и кто искал команду, чтобы её реализовать. Теперь мне кажется, что у них вот‑вот настанет звёздный час.

Пришла в голову идея — тут же реализовал. Пришла другая, лучше — реализовал и её.

Стоунбрейкер и юбилеи Postgres

Ура! 8 июля Postgres‑мир отпраздновал 30-летие любимой СУБД. Опубликован перевод фундаментальной статьи Майкла Стоунбрейкера The Design Of Postgres Storage System ^[82]:

Проектирование системы хранения POSTGRES ^[83]

А в день рождения PostgreSQL опубликовали перевод статьи, которая послужила основой этой СУБД. У неё тоже был юбилей — 40 лет с момента выхода:

Проектирование POSTGRES: как задумывалась популярная СУБД ^[84] — Майкл Стоунбрейкер и Лоуренс Роу (Michael Stonebraker and Lawrence A. Rowe, оригинал статьи: The Design Of Postgres ^[85].

Сейчас считается так: 8 июля у PostgreSQL юбилей — 30 лет. В 1996 году Марк Фурнье (Mark ‘scrappy’ Fournier) из компании Networking Services предоставил первый внешний сервер для разработки опенсорсного проекта Postgres (до этого СУБД разрабатывали на мощностях Калифорнийского университета в Беркли).

Но есть мнение: Postgres — 40-летний, а не 30-летний. Со дня опубликования концепции. Концепция по латыни = зачатие. А вот в некоторых культурах возраст человека отсчитывают не с момента рождения, а с момента зачатия. Знаю, что так у корейцев и у калмыков. Наверняка и у многих других.

Отраслевая пресса не забыла об имениннике и отце именинника: вот, например:

Turing Award Winner: Disagreeing with Google, Postgres, Future Problems ^[86] — часовая беседа с Маклом Стоунбрейкером. Как проект начинался, что не так в базах у Google и Amazon, что пора строить в будущем.

Образование

Вышли курсы PGPRO. Возможности Postgres Pro Enterprise 16 ^[87]. Продолжительность: 4 дня. Предварительные знания:

• знакомство с ОС Unix;

• уверенное владение SQL (знакомство с PL/pgSQL не обязательно, но полезно);

• PostgreSQL в объеме курсов DBA1, DBA2, DBA3 и QPT, либо DEV1, DEV2 и QPT.

Учебные материалы есть по 22 темам, их список есть на странице курсов ^[87].

Open Alliance for PostgreSQL Education ^[88].

Появился на днях. Он будет сертифицировать специалистов по PostgreSQL. Открытый — это значит, что он будет привязан не к одной компании, а к целому списку участников альянса.

Об этой инициативе пишет на Medium ^[89] Корнелия Биачич (Cornelia Biacsics ^[90]) в Building the OAPE PostgreSQL Certification ^[89].

Куда идёт виртуализация

Честный разговор: от классической виртуализации до KubeVirt — видео онлайн от «Флант» ^[91]

В подкасте участвовали:

• Андрей Коновалов, независимый эксперт по виртуализации;

• Дмитрий Горохов, директор направления виртуализации, «Инфосистемы Джет»;

• Георгий Дауман, директор продуктового направления «Виртуализация», «Флант».

Обсудили:

• как изменился рынок виртуализации в России и чего сегодня ждут заказчики;

• чем классическая виртуализация отличается от подхода на базе KubeVirt и DVP;

• как устроены установка, управление, автоматизация и интеграция с инфраструктурой;

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

• в каких сценариях DVP может быть особенно полезна, а где
  стоит учитывать ограничения;

• почему не всегда достаточно просто взять открытый проект и развернуть его самостоятельно.

Конференции: Непал

И опять напоминаем об этой красивой во всех отношениях конференции:

PostgreSQL Conference Nepal, 2026

Постгресовых конференций много хороших и разных, на этот раз анонсируем вот эту ^[92]. Она 4-я по счёту и обещает быть более представительной, чем предыдущие; 4-дневная, пройдёт 18–21 ноября в Катманду. Это, между прочим, не красивая деревушка в горах, а город‑миллионник, а в стране около 30 млн жителей. Так что есть кому предлагать Postgres (правительственные структуры им тоже очень интересуются). Программа формируется, присылайте ДОКЛАДЫ!

Организаторы конференции: Nepal PostgreSQL User Group, Kathmandu University, Institute of Engineering Pulchowk Campus Университета Трибхуван и Postgres Professional. Генеральным спонсором этого года стала местная компания Dharma of Data. В оргкомитете и программном комитете представители Kathmandu University, Postgres Professional, Nepal ICT Foundation, IOE Pulchowk Campus, Outlines Research & Development, Dharma of Data, Beta Analytics и Uniaxial Softwares.

• Сайт конференции ^[92].

• Call for Papers ^[93].

• Регистрация ^[94].

---

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