Postgres 19 наконец дефрагментирует таблицы без блокировок и берёт GROUP BY ALL у DuckDB

Что реально меняется при обновлении

Крейг Керстинс, директор по разработке в Snowflake, проходит по бете Postgres 19 фича за фичей. Главное для эксплуатации это REPACK CONCURRENTLY: встроенная реорганизация таблиц, которая убирает распухание без тяжёлой блокировки и переносит в ядро то, ради чего люди тянулись к расширению pg_repack. Управление партициями тоже стало настоящим: теперь их можно сливать и разбивать на месте, меняя схему без полной перестройки.

Остальное — широкий проход по мелким удобствам. Autovacuum получает параллельных воркеров и систему оценок, чтобы решать, что чистить в первую очередь. Логическая репликация учится синхронизировать значения последовательностей и публиковать ALL SEQUENCES. COPY умеет пропускать строки-заголовки, приводить битые значения через ON_ERROR SET_NULL и выдавать JSON. Появился SQL/PGQ — запросы к property-графам поверх обычных реляционных таблиц, так что графовые запросы можно гонять без отдельной графовой базы; плюс выигрыши планировщика вроде оптимизации анти-джойнов и свёртки констант. И порция SQL-сахара: GROUP BY ALL, IGNORE NULLS в оконных функциях, INSERT … ON CONFLICT DO SELECT и темпоральные UPDATE/DELETE FOR PORTION OF.

Тред спорил о том, чего в релизе нет

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

«Как пользователь Postgres в науке с 15-летним стажем, я начинаю беспокоиться из-за отсутствия колоночного хранения в PostgreSQL. Датасеты растут всё больше, и ограничения хранилища PG становятся всё заметнее.» — астрофизик и дата-сайентист, работающий с Postgres более 15 лет

Другие добавили свои списки недостающего: синхронно обновляемые материализованные представления (индексированные представления SQL Server), которые один инженер назвал элегантными и тривиально корректными для сложных сценариев с данными; API подключаемых движков хранения в духе MariaDB, чтобы можно было воткнуть OLTP/OLAP-бэкенд уровня RocksDB; и, со стороны devops, обновление между мажорными версиями на месте, до сих пор настоящая боль внутри Docker, где pg_upgrade требует старые и новые бинарники бок о бок.

Сноска про DuckDB и жалоба на LLM-текст

Одно из самых залайканных нововведений пришло с примечанием. GROUP BY ALL — реальное удобство, но читатель проследил его происхождение:

«Приятно видеть введённый GROUP BY ALL, который, насколько я знаю, изначально придумал DuckDB.» — комментатор со ссылкой на документацию DuckDB о дружелюбном SQL

Это маленький, но показательный разворот нарратива «Postgres впереди»: несколько SQL-удобств, приезжающих в 19-й, первыми популяризировали более молодые системы, DuckDB в том числе, и лишь теперь их адаптируют вверх по течению. А в очень хакерньюсовском духе часть треда вовсе забыла про базу и принялась ругать текст блога: фразы вроде «Ни одна из этих фич не меняет мир. Но все они делают ежедневную работу с данными лучше» показались читателям приглаженными под LLM, и один пошутил, что Оруэлл выучил бы клингонский, лишь бы их не читать. Но для практикующего DBA суть неказиста и желанна: релиз, который наконец позволяет дефрагментировать горячую таблицу без окна обслуживания, стоит обновления сам по себе.