LINUX.ORG.RU

PostgreSQL 18

 , ,


0

3

25 сентября, после более года разработки, состоялся выпуск стабильной версии 18 свободной объектно-реляционной системы управления базами данных PostgreSQL.

PostgreSQL 18 повышает производительность для рабочих нагрузок любого масштаба благодаря новой подсистеме ввода-вывода, которая показала до 3× ускорение чтения из хранилища, а также увеличивает число запросов, которые могут использовать индексы. Этот релиз делает обновления мажорной версии менее разрушительными, ускоряет сам процесс обновления и сокращает время, необходимое, чтобы после обновления выйти на ожидаемую производительность. Разработчики также выигрывают от функций PostgreSQL 18 — например, виртуальных вычисляемых столбцов, которые рассчитывают значения во время выполнения запроса, и дружественной к СУБД функции uuidv7(), обеспечивающей более быстрые индексацию и чтение UUID. Кроме того, PostgreSQL 18 упрощает интеграцию с системами единого входа (SSO) благодаря поддержке аутентификации OAuth 2.0.

«Усилия глобального сообщества разработчиков ПО с открытым исходным кодом формируют каждый релиз PostgreSQL и помогают предоставлять функции, отвечающие потребностям пользователей там, где находятся их данные, — сказал Джонатан Кац (Jonathan Katz), член основной команды PostgreSQL. — PostgreSQL 18 опирается на долгую и богатую историю проекта по предоставлению надежного и эффективного управления данными, при этом продолжая расширять спектр поддерживаемых рабочих нагрузок.»

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

Основные изменения:

  • Появление асинхронного ввода-вывода (AIO)
    • Ранее для ускорения доступа к данным PostgreSQL полагался на механизм опережающего чтения (readahead) операционной системы. Однако, поскольку операционные системы не понимают специфичных для баз данных паттернах доступа, они не всегда могут предсказать, какие данные потребуются, что приводит к неоптимальной производительности во многих рабочих нагрузках.
    • PostgreSQL 18 внедряет новую подсистему асинхронного ввода-вывода (AIO), разработанную для устранения этого ограничения. AIO позволяет PostgreSQL отправлять несколько запросов ввода-вывода (I/O) параллельно, не дожидаясь последовательного завершения каждого. Это дополняет существующий readahead и улучшает общую пропускную способность. В PostgreSQL 18 поддерживаются операции AIO для последовательных сканирований, сканирований по битовой карте (bitmap) страниц кучи (heap) и вакуума. Сравнительное тестирование продемонстрировало прирост производительности до 3 раз в некоторых сценариях.
    • Новый параметр io_method позволяет выбирать между реализациями AIO, включая worker и io_uring, либо сохранить текущее поведение PostgreSQL с настройкой sync. При включении AIO появляется больше параметров, доступных для тонкой настройки — подробнее в документации.
  • Более быстрые обновления и улучшенная производительность после обновления
    • Ключевая особенность PostgreSQL — сбор и хранение статистики, которая помогает планировщику выбирать наиболее эффективный план запроса. До PostgreSQL 18 эта статистика не переносилась между экземплярами при обновлении мажорной версии, что могло вызывать заметную деградацию производительности запросов на нагруженных системах до завершения выполнения операции ANALYZE. В PostgreSQL 18 появилась возможность сохранять статистику планировщика при обновлении мажорной версии, что позволяет обновлённому кластеру быстрее выйти на ожидаемую производительность.
    • Кроме того, утилита pg_upgrade, предназначенная для обновления между мажорными версиями, получила ряд улучшений в PostgreSQL 18, включая более быстрые обновления, когда в базе много объектов, таких как таблицы и последовательности. Этот выпуск также позволяет pg_upgrade обрабатывать свои проверки параллельно в зависимости от настроек флага --jobs и добавляет флаг --swap, позволяющий менять местами каталоги обновления вместо копирования, клонирования или связывания файлов.
  • Улучшения производительности запросов и общие оптимизации
    • PostgreSQL 18 дополнительно повышает производительность запросов благодаря функциям, которые автоматически ускоряют выполнение рабочих нагрузок. В этом выпуске представлены функции поиска «skip scan» по многоколоночным индексам B-дерево, улучшающие время выполнения запросов, в которых отсутствует условие = для одной или нескольких первых колонок индекса. Также оптимизируются запросы с условиями OR в WHERE, позволяя использовать индекс и существенно сокращая время выполнения. Также внесены многочисленные улучшения в планирование и выполнение соединений таблиц PostgreSQL: от ускорения хеш-соединений (hash join) до возможности использования инкрементальных сортировок в соединениях слиянием (merge join). PostgreSQL 18 также поддерживает параллельное создание GIN-индексов, дополнив этим B-деревья и BRIN-индексы, которые уже поддерживали такую возможность.
    • Релиз также развивает поддержку аппаратного ускорения: добавлены инструкции ARM NEON и SVE центрального процессора для встроенной функции popcount, которую использует bit_count и другие внутренние механизмы.
  • Улучшение опыта разработчика
    • PostgreSQL 18 вводит виртуальные вычисляемые столбцы, значения которых вычисляются во время выполнения запроса вместо хранения на диске (это теперь поведение по умолчанию для вычисляемых столбцов). Кроме того, «хранимые» вычисляемые столбцы теперь поддерживаются в логической репликации.
    • В этой версии появилась возможность получать как прежние (OLD), так и текущие (NEW) значения в предложении RETURNING для команд INSERT, UPDATE, DELETE и MERGE. PostgreSQL 18 также добавляет генерацию UUIDv7 с помощью функции uuidv7(), позволяя создавать случайные UUID, упорядоченные по временной метке, что улучшает стратегии кэширования. Кроме того, в PostgreSQL 18 функция uuidv4() добавлена как псевдоним gen_random_uuid().
    • PostgreSQL 18 добавляет временные ограничения — ограничения по диапазонам — для PRIMARY KEY и UNIQUE с использованием конструкции WITHOUT OVERLAPS, а также для FOREIGN KEY с использованием PERIOD.
    • Наконец, стало проще создавать схему внешней таблицы на основе локальной: добавлена команда CREATE FOREIGN TABLE … LIKE.
  • Улучшенная обработка текста
    • PostgreSQL 18 упрощает и ускоряет работу со строками благодаря нескольким улучшениям. В этом выпуске добавлена сортировка PG_UNICODE_FAST, которая обеспечивает полноценную семантику Unicode для преобразования регистра, помогая ускорить многие сравнения. Это касается функций upper и lower, а также новой функции casefold для регистронезависимых сравнений. Кроме того, PostgreSQL 18 теперь поддерживает выполнение сравнений LIKE над текстом с недетерминированной сортировкой, что упрощает сложный поиск по шаблону. В этом релизе также изменено поведение полнотекстового поиска: теперь он использует поставщика сортировки по умолчанию для кластера вместо принудительного использования libc. Это может потребовать пересоздания всех индексов полнотекстового поиска и pg_trgm после выполнения pg_upgrade.
  • Аутентификация и безопасность
    • PostgreSQL 18 добавляет аутентификацию oauth, позволяющую пользователям проходить проверку подлинности с использованием механизмов OAuth 2.0, поддерживаемых через расширения PostgreSQL. Кроме того, PostgreSQL 18 добавляет проверку режима FIPS и новый параметр ssl_tls13_ciphers для настройки наборов шифров TLS v1.3 на стороне сервера.
    • В этом выпуске прекращена поддержка аутентификации по паролю md5 (будет удалена в одном из будущих релизов). Если вам требуется парольная аутентификация в PostgreSQL, используйте SCRAM-аутентификацию. PostgreSQL 18 также поддерживает сквозную аутентификацию SCRAM с помощью postgres_fdw и dblink для аутентификации на удалённых экземплярах PostgreSQL. Кроме того, pgcrypto теперь поддерживает шифрование паролей с использованием SHA-2.
  • Репликация
    • PostgreSQL 18 поддерживает регистрацию конфликтов записи при логической репликации в журналах и в представлении pg_stat_subscription_stats. Кроме того, теперь команда CREATE SUBSCRIPTION по умолчанию применяет транзакции в несколько параллельных потоков, что может повысить производительность. Утилита pg_createsubscriber получила флаг --all, позволяющий создавать логические реплики для всех баз данных в экземпляре одной командой. Также PostgreSQL 18 позволяет автоматически удалять неактивные слоты репликации, чтобы избежать избыточного накопления файлов журнала предзаписи (WAL) на стороне публикующего сервера.
  • Обслуживание и наблюдаемость
    • PostgreSQL 18 улучшает стратегию очистки, путём упреждающей заморозки большего количества страниц во время регулярной очистки, что снижает накладные расходы и помогает в ситуациях, требующих агрессивной очистки.
    • PostgreSQL 18 добавляет больше информации в EXPLAIN, который предоставляет информацию о выполнении плана запроса, и, начиная с этого выпуска, теперь автоматически показывает, сколько буферов (основной единицы хранения данных) используется при выполнении EXPLAIN ANALYZE. Кроме того, EXPLAIN ANALYZE показывает количество обращений к индексу при его сканировании, а EXPLAIN ANALYZE VERBOSE включает статистику использования процессора, WAL и средним временам чтения. В представлении pg_stat_all_tables появилась дополнительная информация о времени, затраченном на очистку и связанные с ней операции, а также статистику ввода-вывода и использования WAL по каждому соединению.
  • Прочие заметные изменения
    • Базы данных, инициализированные с помощью initdb в PostgreSQL 18, теперь по умолчанию создаются с включёнными контрольными суммами страниц. Это может повлиять на обновления с кластеров, где контрольные суммы выключены: при использовании pg_upgrade для обновления таких кластеров потребуется создать новый кластер PostgreSQL 18 с опцией --no-data-checksums.
    • Кроме того, PostgreSQL 18 представляет новую версию (3.2) протокола взаимодействия (wire protocol) PostgreSQL — первое обновление протокола с момента выхода PostgreSQL 7.4 (2003 год). При этом libpq по умолчанию по-прежнему использует версию 3.0, пока клиенты (например, драйверы, пулеры, прокси) не добавят поддержку новой версии протокола.
  • Дополнительные возможности
    • Множество других новых функций и улучшений также вошли в PostgreSQL 18 и могут оказаться полезными для ваших сценариев. Полный список новых и изменённых возможностей приведён в примечаниях к релизу.

>>> Подробности на postgresql.org

★★★★★

Проверено: Dimez ()
Ответ на: комментарий от MaZy

Потому что это очевидное очевидно ровно до тех пор, пока ты на практике не начнешь сам этим заниматься. А потом возникают нюансы и все не так уж и очевидно. Есть о чем рассуждать.

LightDiver ★★★★★
()
Ответ на: комментарий от ivanich10

Во-первых тогда clickhouse не придумали.

Во-вторых я сомневаюсь, что clickhouse запустится на windows 2003 с 2 GB RAM.

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

vbr ★★★★★
()
Ответ на: комментарий от vbr

В HTTP нет никакого особого значения у символов ? и &. То, что сервер их интерпретирует каким-то специальным образом, это только его дело, никто не мешает их интерпретировать как угодно.

Символ «?», отделяющий query, описан в RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax, на который ссылаются RFC, описывающие HTTP.

static_lab ★★★★★
()
Последнее исправление: static_lab (всего исправлений: 2)
Ответ на: комментарий от static_lab

Это просто рекомендации.

nothing in this specification prevents an application from limiting itself to particular types of resources, or to a subset of URIs that maintains characteristics desired by that application.

С технической точки зрения важно лишь то, какие символы пропускает браузер, прокси и реверс-прокси на пути от URL-а до конечного сервера, обрабатывающего запрос. В любом HTTP-фреймворке, с которыми я до сих пор работал, есть возможность получить URL path в исходном виде и использовать его как душе угодно.

Но я, конечно, не призываю использовать все эти странные символы в URL. Это была просто попытка довести аргумент до абсурда. Лично я кодировать UUID во что-либо кроме каноничной формы буду лишь от скуки.

vbr ★★★★★
()
Ответ на: комментарий от vbr

С технической точки зрения важно лишь то, какие символы пропускает браузер, прокси и реверс-прокси

А вот в этом моменте RFC 9110 - HTTP Semantics явно говорит пропускать query:

A proxy MUST NOT modify the «absolute-path» and «query» parts of the received target URI when forwarding it to the next inbound server except as required by that forwarding protocol.

Да, правила такие, что по сути их можно не принимать в расчёт, но они всё-таки явно прописаны такими.

static_lab ★★★★★
()
Ответ на: комментарий от LightDiver

нужно оптимизировтаь.

И чтобы не вставлять себе палки в колёса в бущем, оптимизировать ОЧЕВИДНЫЕ вещи нужно ПРЕЖДЕВРЕМЕННО, не пытаясь молиться на кнута. «Корень всех зол» - хорошо говорить, когда коммунизм и сервера бесплатные.

lesopilorama
()
Ответ на: комментарий от kaldeon

хз как у других

скажу за себя

листание Дейты как то было видимо не ко времени - как и прочих ещё более третичных мануалов по sql и cубд с нею

реально «прорыв понимания » произошёл после листания одной из книг Ульмана (который ещё и компиляторы с Ахой и Хопкрофтом) о дата ссаенсе и бд с Гарсией - но понимание окончательное после

Программист - навигатор 

https://amturing.acm.org/award_winners/bachman_9385610.cfm

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

qulinxao3 ★☆
()
Ответ на: комментарий от vbr

Это который падает постоянно и для поднятия которого надо вызывать СЕРТИФИЦИРОВАННОГО СПЕЦИАЛИСТА, который магическими командами его поднимает?

Нет, всё намного-намного хуже :)

Видишь ORA-600 ошибку, обращаешься к сертифицированному специалисту, тот говорит «у меня лапки, нужен металинк», обращаешься к ораклу, а тот в ответ «мы обнаружили ваш старый контракт, который кончился 10 лет назад, для возобновления доступа оплатите металинк за 10 неоплаченных лет, недополученная прибыль жеж!», фьють-ха :)

Dimez ★★★★★
()
Ответ на: комментарий от lesopilorama

И чтобы не вставлять себе палки в колёса в бущем, оптимизировать ОЧЕВИДНЫЕ вещи нужно ПРЕЖДЕВРЕМЕННО, не пытаясь молиться на кнута.

До того, как проект поднят и работает в проде, почти невозможно понять, какие вещи ОЧЕВИДНО требуют оптимизации.

Chiffchaff
()
Ответ на: комментарий от qulinxao3

Ульман - Основы систем баз данных(1983ФиС1980CSpressStanford)

глава 3 ТРИ ЗАМЕЧАТЕЛЬНЫХ МОДЕЛИ ДАННЫХ 72
3.1 Реляционная мд                      72
3.2 Сетевая мд                          81
3.3 Иерархическая мд                    87
3.4 Сравнение м                         93
У                                       96
Библио                                  97
qulinxao3 ★☆
()
Ответ на: комментарий от qulinxao3
глава 2 ФИЗИЧЕСКАЯ ОРГАНИЗАЦИЯ ДАННЫХ
2.1 Модель организации внешней памяти
2.2 Хешированные файлы
2.3 Индексированные файлы
2.4 В-деревья
2.5 Файлы с плотным индексом
2.6 Файлы с записями переменной длины
2.7 Структуры данных для поиска по неключевым полям
2.8 Поиск по частичному соответствию
У & Библио
глава 1. ОБЩЕЕ ПРЕДСТАВЛЕНИЕ О СИСТЕМЕ БАЗ ДАННЫХ
1.1 Система баз данных
1.2 Уровни абстракции в СУБД
1.3 Различия восприятий базы данных
1.4 Модель реального мира
У & Библио

42 тому как - значли в советии какие буклеты переиздавать тиражами в 20к

qulinxao3 ★☆
()
Ответ на: комментарий от Dimez

Видишь ORA-600 ошибку, обращаешься к сертифицированному специалисту, тот говорит «у меня лапки, нужен металинк», обращаешься к ораклу, а тот в ответ «мы обнаружили ваш старый контракт, который кончился 10 лет назад, для возобновления доступа оплатите металинк за 10 неоплаченных лет, недополученная прибыль жеж!», фьють-ха :)

уровень компетенции аж зашкаливает. ORA-600 встречается куда реже чем ORA-07445, ну и вообще эксплуатант обычно с чем-то подобным сталкивается не чаще чем раз в 5 лет (чтобы ловить почаще нужно БД иметь не мелкие, включать довольно спорные фичи и еще и запросы монструозные писать - PostgreSQL до такого режима эксплуатации не дорастет уже никогда - он на 10 таблиц план составить не в состоянии). У «специалистов» обычно есть доступ к oracle support в части KB - он стоит совсем не дорого, баги без живого CSI заводить, естественно никто не даст, но а что вы ожидали от коммерческого продукта?

Меж тем у Oracle ну очень достойная KB, которая скорее всего основную ценность-то и представляет, т.е. знания, накопленные за 45 лет, которые пополнялись разными людьми, с разными ожиданиями от продукта и пр. - даже если сейчас начать БД разрабатывать с нуля и обложиться исключительно книжками по CS и реляционной теории, то ничего из этого не выйдет кроме очередной акдемической поделки, в отличии от - без реальных юзкейсов продукт сделать не получится.

А теперь, будьте любезны, покажите KB для PostgreSQL

borisych ★★★★★
()
Ответ на: комментарий от borisych

уровень компетенции аж зашкаливает. ORA-600 встречается куда реже чем ORA-07445

Ото ж. Давно свалил с оракла (11gr2 последний релиз был, но уже на излёте) и доволен. ORA-600 видел, исправлял патчсетами и патчами, ORA-07455 не видел

Dimez ★★★★★
()
Ответ на: комментарий от qulinxao3

вы окак консультант?!

не, я обычная жава-макака, но имел возможность общаться и с теми и другими, у консультантов PostgreSQL методичка обычно такая:

  • пересоберите статистику
  • добавьте индексов
  • перестройте индексы
  • разработчики пишут плохие запросы

Встречаются, правда, приятные исключения, например Laurenz Albe - но это уже разработчик.

borisych ★★★★★
()
Ответ на: комментарий от borisych

уже разработчик а сайт речекряк правильный

Relational Software утащили имя из проекта безопаснтности толи внутреней толи внешней

ну и если посмотреть(благо ща инеты позволяют) первые версии ну и парралельно их маркетинговые(да и доки) презы - очень щикотно получается в отличии их той семантики от их же в следующих версиях когда оно наконец-то было прикручено

и окак тот ещё бизнес-серьёзно - большим корпам большие системы

тока как то так получается что большие обычно не голодны к улучшениям и проще объест клиента которые с подлодкой срослись

а так конечно лучше окак ля нет ничего!

qulinxao3 ★☆
()
Ответ на: комментарий от LightDiver

да кто все-то? я только на лоре и вижу про него, да и то, сколько там активно обсуждающий? Что-то не видно никаких обcуждений ни на реддитах/твиттерах. Если бы он был «такого уровня», то давно бы перевели и притащили и теже разрабы постгри объясняли почему он неправ. Вон dhh базы навалил и даже до меня долетает, хотя я с коммьюнити ror вообще никак не пересекаюсь

Не сможет ничего перетряхнуть человек, который на любой вопрос, про что-то, что ему не нравится, отвечает в стиле «ты чудак, все равно ничего не поймешь» и не предлагает никаких альтернатив.

user_undefined ★★
()
Ответ на: комментарий от lesopilorama

Просто с опытом уже знаешь как нужно делать правильно. И стараешься делать именно так. Оно в целом проще.

LightDiver ★★★★★
()
Ответ на: комментарий от vbr

Благодарю, теперь понятно.

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

Это как раз понятно.

В новости подача такая, что ВЫ ВСЕ УМРЁМ!

Или предварительно в старой включить контрольные суммы.

Дома включены (но я не помню когда я это сделал):

 $ pg_checksums --check /var/db/postgres/data17
Checksum operation completed
Files scanned:   8070
Blocks scanned:  523699
Bad checksums:  0
Data checksum version: 1

В остальных местах проверю перед миграцией.


Для тех, кто не понял (как и я изначально ☺), отключать чексуммы в новом кластере не обязательно, достаточно включить их в старом перед миграцией:

 # service postgresql stop
 % pg_checksums --enable /path/to/data17
 % initdb /path/to/data18
 % pg_upgrade --old-datadir /path/to/data17 --new-datadir /path/to/data18 ...
 # service postgresql start

// Они шесть лет обкатывали это дело, прежде чем вкатить как дефолт.

mord0d ★★★★★
()
Ответ на: комментарий от lesopilorama

как ни страно

у Плоджера в его первом томе

Programming on Purpose: Essays on Software Design, Volume 1 Author P. J. Plauger

кодекс в 1994 а статья из 1986-1987 буквально тэйк

что правильно сразу это есть опыт(чуйка)

с первонаха обычно выбрось и перепиши

qulinxao3 ★☆
()

поддерживаются операции AIO для последовательных сканирований, сканирований по битовой карте (bitmap) страниц кучи (heap) и вакуума

AIO operations supported in PostgreSQL 18 include sequential scans, bitmap heap scans, and vacuum.

Не знаю как по-русски это переводят, но имеется ввиду не «вакуум», а «пылесосинг» (gc)

«поддерживаются операции AIO для последовательных сканирований, сканирований по битовой карте (bitmap) страниц кучи (heap) и пылесосинга»

alois
()
Последнее исправление: alois (всего исправлений: 2)
Ответ на: комментарий от YogSagot

Для клоунаторов новости. :)

dataman ★★★★★
() автор топика
Ответ на: комментарий от vbr

Какая бы ни была конкуренция, скорость записи на диск это главный фактор. Если 10 потоков записывают по 10 строк, лучше они будут это делать в конец индекса, пусть и по очереди, это будет быстрей, чем если они будут делать это одновременно в разные части индекса.

ох… нужно прекращать читать интернеты и начинать читать исходный код, а потом еще выдавать гипотезы и их проверять.

  1. идем и читаем src/backend/access/nbtree/README
  2. там пишут, что в страницу индекса одновременно может писать только один бэкенд, ну и для защиты там используется стандартная rw-блокировка
  3. складываем все вместе и получаем, что в монотонный PK (да и вообще в любой монотонный индекс) одновременно может писать только один бэкенд, т.е. сколько бы мы дров в БД не подкладывали и во сколько потоков мы бы не вставляли данные, один хрен оно будет медленно

таким образом, если БД организована так, что в нее постоянно льют мусор, при этом очень много, то монотонных PK стараются избегать, достигается это довольно простыми способами:

  • рандомный суррогатный ключ (читать UUID)
  • перетасовывание битов в монотонном ключе - если в int64 даже тупо переставить местами первый и последний байт, то уже профит получается
  • подмешивание в монотонный ключ информации о сеансе, например: https://oracle-base.com/articles/18c/scalable-sequences-18c

UUIDv7 на самом деле нифига не монотонный с точки зрения индекса - там половина ключа рандомные данные, т.е. ключи на UUIDv7 «пухнут» ровно точно также как и на UUIDv4, разве что в первом случае высота индекса может быть на 1 меньше. Да, было бы круто, если бы все бранчи индекса лежали в памяти, чему увеличенная высота индекса явно не способствует, но (!) если убрать к чертям эти UUID и использовать уже 64-битные ключи (как правильные разработчики и делают), то индекс станет тупо в 2 раза меньше.

на этом фоне заявления про невероятную экономию в 20%, код от Васяна, потребность в саб-миллисекундном разрешении (зачем там вообще дата-то нужна?) и невероятные успехи PostgreSQL на этом поприще видятся просто смешными.

borisych ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.