LINUX.ORG.RU

PostgreSQL 15 с улучшенной производительностью сортировки, поддержкой сжатия LZ4 и Zstd

 , ,


1

2

Спустя год разработки вышла новая стабильная версия реляционной СУБД PostgreSQL под номером 15. PostgreSQL 15 обеспечивает ряд улучшений производительности, добавляет команду «MERGE», включает поддержку сжатия Zstd и LZ4 и ряд других новшеств.

Улучшения в части повышения производительности:

  • улучшены алгоритмы сортировки в памяти и на диске, а тесты показывают ускорение от 25% до 400% в зависимости от того, какие типы данных сортируются;
  • улучшена производительность функций row_number(), rank(), dense_rank() и count(), когда они используются как оконные;
  • запросы с использованием SELECT DISTINCT теперь могут выполняться параллельно;
  • postgres_fdw — модуль доступа к сторонним данным PostgreSQL — теперь поддерживает асинхронные фиксации;
  • поддержка сжатия LZ4 и Zstandard (zstd) для файлов журнала упреждающей записи (WAL);
  • дополнительные параметры логической репликации;
  • новые функции для использования регулярных выражений;
  • новый формат ведения журнала с использованием JSON: jsonlog.

Другие заметные изменения:

  • статистика на уровне сервера теперь собирается в разделяемой памяти, что позволило исключить отдельный процесс сбора статистики и периодический сброс собранной статистики на диск;
  • предоставлена возможность сделать параметры сортировки ICU параметрами сортировки по умолчанию для кластера или отдельной базы данных;
  • добавлено новое встроенное расширение pg_walinspect, которое позволяет пользователям проверять содержимое файлов журнала с упреждающей записью непосредственно из интерфейса SQL;
  • отменены разрешения CREATE у всех пользователей, кроме владельца базы данных из общедоступной схемы (или схемы по умолчанию);
  • удален как давно устаревший режим «эксклюзивного резервного копирования»;
  • удалена поддержка Python 2 из PL/Python.

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 18)

улучшены алгоритмы сортировки в памяти и на диске, а тесты показывают ускорение от 25% до 400%

Прям интересно стало. Есть ссылка на коммит или надо идти реп рыть?

upcFrost ★★★★★
()

ускорение от 25% до 400%

разрабы узнали о существовании sse4 и avx2

voltmod ★★
()

функции row_number(), rank(), dense_rank(), and count() могут использоваться как оконные функции, что тоже повышает производительность работы PostgreSQL 15;

Сам-то Postgres шатаешь, браток? ПРАВИЛЬНЫЙ ПЕРЕВОД™ таков: «Улучшена производительность функций row_number(), rank(), dense_rank() и count(), когда они используются как оконные.»

P.S. Специально добавил пассивно-агрессивную колкость в комментарий чтоб добавить перчинки в обсуждение и оживить тред :3

perl5_guy ★★★★★
()
Последнее исправление: perl5_guy (всего исправлений: 2)

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

это надо еще раз 10 прочитать. а потом как-то изменить

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

Там и в оригинале довольно мутно написано. Я так понял, что такая организация исключает тормоза, связанные со сбросом этой статистики на диск и межпроцессным взаимодействием (а может, не тормоза, а итоговые искажения самой статистики).

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

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

aol ★★★★★
()
Последнее исправление: aol (всего исправлений: 1)

добавляет команду «MERGE»

И что оно делает? Как применять?

тесты показывают ускорение от 25% до 400%

Пфф… Я могу такой разницы добиться на разных инстансах одной версии… А тут вообще, подозреваю, тесты чисто синтетические, а в полевых условиях оно может оказаться и наоборот.

row_number(), rank(), dense_rank(), и count() могут использоваться как оконные функции

Эээ… А что, раньше их нельзя было пользовать как оконные?! А меня не предупредили, я использовал и оно даже работало! (%

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

Если это будет работать как я думаю, то очень хорошо.

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

До них дошло! ☺

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

из прочтенного в оригинале, я делаю вывод, что был исключен отдельный процесс сбора статистики

Да-да, я тоже так подумал! Это единственная гипотеза объясняющая слово both между упоминанием этого процесса и записи на диск.

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

«Улучшена производительность функций […], когда они используются как оконные

ЧТД. (третий абзац этого комментария)

P.S. Специально добавил пассивно-агрессивную колкость в комментарий чтоб добавить перчинки в обсуждение и оживить тред :3

Ой, на ЛОРе ни один тред не обходится без «перчинки в обсуждении»

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

улучшены алгоритмы сортировки в памяти и на диске, а тесты показывают ускорение от 25% до 400%

Прям интересно стало. Есть ссылка на коммит или надо идти реп рыть?

Мне вот тоже интересно.

Improve performance for sorts that exceed work_mem (Heikki Linnakangas)

When the sort data no longer fits in work_mem, switch to a batch sorting algorithm that uses more output streams than before.

Improve performance and reduce memory consumption of in-memory sorts (Ronan Dunklau, David Rowley, Thomas Munro, John Naylor)

Да, нужно репы смотреть. Но судя по этим описаниям, я подозреваю, что 400% это от смены алгоритма сортировки, и больше потоков, если в память не влезает. А 25% это скорее мелкий рефакторинг…

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

Пакеты уже завезли в неё?

кто о чем, а вшивый о бане. В PostgreSQL нельзя толком ни колонку поменять, ни удалить ни в таблице ни во вьюхе, если кто-то другой для своего удобства создал свои вьюхи, в следствие чего любое даже незначительное обновление схемы превращается в операцию «снести все и установить только то, про что точно знаем». А тут видите ли кому-то пакетов не хватает…

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

Спасибо, а то я завис на этой фразе. А как оно раньше-то работало? Всё-таки переводить новости надо хотя бы приблизительно понимая, о чём речь…

emorozov
()
Ответ на: комментарий от perl5_guy

Спасибо за уточнение, а то я по тексту здесь и на опенете так и не понял в чем провинились эти функции.

MichIs
()
Ответ на: комментарий от vasya_pupkin

Пакеты уже завезли в неё?

Щас набежит школота и объяснит вам, что бизнес-логику надо писать на уровне сервера приложений на ООП языках, не предназначенных для написания этой бизнес логики :)

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

В PostgreSQL нельзя …

Бесплатной СУБД в зубы не смотрят.

ПС. Сейчас наметилась какая-то нездоровая тенденция перехода с Oracle DB, M$ Sql Server на варианты PostgreSQL даже не в самых подходящих областях для этого. Никто не запрещает делать переход более плавно, продуманно и с меньшими затратами, так как имеющиеся версии Oracle DB и SqlServer могут спокойно прослужить еще лет 10-15. А так - нужен проект Национальной СУБД уровня Oracle - это действительно насущная проблема, и з а месяц или год она не решается.

MichIs
()

@emorozov

Спасибо, а то я завис на этой фразе…

@MichIs

Спасибо за уточнение, а то я по тексту здесь и на опенете так и не понял в чем провинились эти функции.

Да позязя \0/ :3

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

Да, это же просто офигительно, когда бизнес-логика разнесена по двум разным местам, и написана на языках, которые находятся на максимально далёком расстоянии друг от друга. Всё это так приятно и удобно синхронизировать по версиям друг-друга. Чтобы разбираться в проблемах, когда что-то работает не так, надо знать минимум два языка, один из которых точно будет выглядеть совершенно чужеродным для разработчика…

Сплошное удобство и выгоды!

emorozov
()
Ответ на: комментарий от perl5_guy

А исправлять новости на LOR нельзя? В тексте новости до сих пор висит этот перл.

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

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

MichIs
()

поддержка сжатия LZ4 и Zstandard (zstd) для файлов

Это должно делаться на уровне FS. Нет никакого смысла дублировать это или выносить на другой уровень.

Разве если база работает на блочном устройстве напрямую.

lefsha
()
Ответ на: комментарий от MichIs

Сейчас наметилась какая-то нездоровая тенденция перехода с Oracle DB, M$ Sql Server на варианты PostgreSQL даже не в самых подходящих областях для этого.

Ну как нездоровая? Вы же в курсе, как Оракл любит и любил своих клиентов? Не оплатили техподдержку за год — больше Оракл вам НИКОГДА и НИЧЕГО не продаст. А теперь Оракла в России больше нет. Просто нет.

Никто не запрещает делать переход более плавно, продуманно и с меньшими затратами, так как имеющиеся версии Oracle DB и SqlServer могут спокойно прослужить еще лет 10-15.

Если исходить из того, что имеющееся железо с Ораклом на борту прослужит те же 10-15 лет — да. А вот если не прослужит — тут возможны самые разные сюрпризы. По эффекту домино, например «новое железо не поддерживает старую ОС, новая ОС не поддерживает купленный за сотни нефти Oracle Database».

Я тоже за то, чтобы делать плавно и продуманно. Обеими руками. Вот только вот какая штука. У нас уже делали плавно и продуманно. В результате даже после 2014 года многие даже пальцами не пошевелили и продолжили действовать исходя из принципа «Oracle и Windows будут всегда». А теперь да, оказывается, что плавно и продуманно надо было начинать лет 10 назад, а сейчас надо срочно гасить пожар.

Похожий пример, правда, не из области СУБД: на ЛОРе недавно проскакивала новость о запуске Компаса под линуксом. …С использованием wine! В 2022 году, Карл! И про необходимость выпуска нативной линуксовой сборки речь зашла только сейчас, в 2022 году!

А так - нужен проект Национальной СУБД уровня Oracle - это действительно насущная проблема, и з а месяц или год она не решается.

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

Бесплатной СУБД в зубы не смотрят.

А это уже просто эталонное невежество. PostgreSQL не обязан быть бесплатным. О существовании Postgres Pro и разных вариантов коммерческой техподдержки на PostgreSQL вы, как я понимаю, не в курсе?

hobbit ★★★★★
()

улучшены алгоритмы сортировки

Видимо вот про это:

Before PostgreSQL 15, we used the polyphase merge algorithm (Knuth's Algorithm 5.4.2D), but with modern hardware, a straightforward balanced merge is better
./src/backend/utils/sort/tuplesort.c

Любопытным остается прочитать Кнута и понять что ж такого в современном железе, что простое слияние лучше.

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

А это уже просто эталонное невежество. PostgreSQL не обязан быть бесплатным. О существовании Postgres Pro и разных вариантов коммерческой техподдержки на PostgreSQL вы, как я понимаю, не в курсе?

Бог, мой. Конечно же я не в курсе. Я даже не в курсе о том, что где-то за окияном есть такая версия PostgreSQL как Enterprise DB, где реализован язык максимально близкий к PL/SQL и его пакетам, и на который мигрировать решения из Oracle одно сплошное удовольствие так как там есть специально заточенные под это инструменты, а не та попаболь как в России при миграции на PostgreSQL Pro, у которых так много «компетенций», что такие вещи как в Entrprise DB у них появятся совсем еще не скоро или не появятся вообще.

Я не в курсе, что большинство заказчиков выбирают простую, бесплатную версию PostgreSQL, а не PostgreSQL Pro - потому что зачем платить за авно, посыпанное солью и перцем, если оно все равно авно?

Я не в курсе, что для решений для хранилищ выбирают либо ArenaData DB, либо GreenPlum.

Я не в курсе, что PostgreSQL по своим возможностям еще не догнала 20 летнюю версию Oracle 9i, не говоря уже про современный версии.

Спасибо вам, что просветили дедушку, а то бы я и не знал про все это - так бы и умер пень пнём :)

ПС. при всем при этом, к товарищам из PostgreSQL Pro я отношусь позитивно - все таки что-то они делают в деле базостроения в России. Но часто они больше пи…говорят, чем реально стоит их «поддержка» и «навороченные фичи».

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

И что оно делает? Как применять?

Цитируя Опеннет:

Добавлена поддержка SQL-команды «MERGE», напоминающей выражение «INSERT … ON CONFLICT». MERGE позволяет создавать условные SQL-выражения, объединяющие в одном выражении операции INSERT, UPDATE и DELETE. Например, при помощи MERGE можно организовать слияние двух таблиц, вставляя недостающие записи и обновляя существующие.

   MERGE INTO customer_account ca
   USING recent_transactions t
   ON t.customer_id = ca.customer_id
   WHEN MATCHED THEN
     UPDATE SET balance = balance + transaction_value
   WHEN NOT MATCHED THEN
     INSERT (customer_id, balance)
     VALUES (t.customer_id, t.transaction_value);
SkyMaverick ★★★★★
()
Ответ на: комментарий от MichIs

Ну вот, оказывается, всё знаете. И зачем тогда было набрасывать про «бесплатную СУБД»?

Я не в курсе, что PostgreSQL по своим возможностям еще не догнала 20 летнюю версию Oracle 9i, не говоря уже про современный версии.

А вот тут хотелось бы (повторюсь) список недостающих возможностей. Причём желательно нужных Вам. А то будет как с GIMP, который на ЛОРе только самый ленивый анонимус не пинал за отсутствие CMYK, при том, что процент тех, кому этот CMYK реально нужен, сильно меньше легиона набрасывающих анонимусов. (И сейчас он, наконец, появился.)

Про процедурный язык я услышал. Да я и сам выше жаловался насчёт пакетов. Что-нибудь ещё?

P.S. Команда Postgres Pro вкладывается не только в базостроение в России, но и вносит вклад в основную ветку PostgreSQL, полагаю, Вам это тоже известно?

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 3)

Самое сложное в сабже - написать conf-файл, чтоб стартанул postgres.

projectorist
()
Ответ на: комментарий от hobbit

… Команда Postgres Pro вкладывается не только в базостроение в России, но и вносит вклад в основную ветку PostgreSQL,..

А перевод документации просто шикарен. Или это не они переводят?

P.S. Упс… Ещё звёздочка появилась.

qwe ★★★
()
Последнее исправление: qwe (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.