LINUX.ORG.RU

Postgresql 13

 ,


2

3

24 сентября команда разработчиков сообщила о выходе очередного релиза Postgresql под номером 13. В новом выпуске основное внимание, среди прочего, было уделено повышению производительности, ускорению внутренних служб обслуживания и упрощению мониторинга базы, а также более надежному контролю доступа к системе.

Продолжилась работа над оптимизацией индексирования таблиц в плане обработки дубликатов среди индексируемых данных в двоичных деревьях индексов, что позволило не только ускорить исполнение запросов, но еще и сократить занимаемое индексом дисковое пространство. Кроме этого, добавлен алгоритм инкрементальной сортировки, при котором повторная сортировка уже отсортированных на предыдущих шагах данных работает быстрее, а у части запросов ускорения можно добиться благодаря применению новой расширенной статистики (через команду CREATE STATISTICS) при вычислении более эффективного пошагового плана. Также оптимизировано выполнение запросов с затратной агрегацией данных путем более широкого применения хэшированной агрегации и сброса части агрегированных данных на диск, если они не помещаются в оперативную память. Отмечается значительный прирост скорости соединения таблиц, расположенных на разных разделах.

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

Среди нововведений для разработчиков стоит выделить функцию datetime(), преобразующую различные стандартные форматы записи времени во встроенный тип Postgresql; доступную из коробки функцию генерации UUID v4 gen_random_uuid(); нормализацию работы с юникодом; более гибкую систему распределения данных таблицы на связанных сетевых узлах базы с полноценной репликацией на логическом уровне, а также другие изменения в запросах и новых доступных для реплик триггерах.

Контроль доступа к базе заявляется как один из ключевых компонентов системы, и в новой версии в этом плане сделаны большие шаги вперед. Теперь установку расширений к базе может выполнять только привилегированный пользователь (superuser). При этом обычные пользователи самостоятельно смогут устанавливать только те расширения, которые помечены им как надежные, либо небольшое множество расширений, считающихся надежными по умолчанию (например, pgcrypto, tablefunc или hstore). При аутентификации пользователей с помощью механизма SCRAM (при работе через драйвер libpq) теперь требуется «привязка канала», а функция-обертка для сторонних данных postgres_fdw с 13-ой версии поддерживает авторизацию по сертификату.

Примечания к выпуску

Страница загрузки

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

★★★★★

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

Очень круто. Лучшая sql субд.

nikolnik ★★★
()

Ну что, ждём в гости фанбоев nosql-я и триггеро-процедуро-фобов? ))

И обязательно поднять тему «Есть ли жизнь без ORM-а?» и её продолжение «С ORM-ом - разве это жизнь?» ))

yyk ★★★★★
()

Ораклокапец, глава 13

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

фанбоев nosql-я и триггеро-процедуро-фобов

Как будто это что-то плохое. Нафига тебе для OLTP целый SQL, да ещё с процедурами?

no-such-file ★★★★★
()

медленные инсерты на таблицах с миллионами строк уже пофиксили? для bulk инсертов до сих пор предлагают утилиту вызывать?

slyjoeh ★★★
()

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

d9d9 ★★★★
()

Ох уж эта мода гонки мажорных версий. Только недавно на 10-ю перешли, а тут 13-ю выкатывают.

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

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

slovazap ★★★★★
()

доступную из коробки функцию генерации UUID v4 gen_random_uuid()

Это надо было сделать ещё 20 лет назад.

dimgel ★★★★★
()

Немалая работа была проведена и в области упрощения обслуживания и администрирования баз данных Postgresql.

Бгг. Можно подумать, его сложно обслуживать и администрировать. Одна из самых неприхотливых СУБД на свете.

UPD. Из крупных – так самая. Впрочем, репликацию ейную я не юзал.

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

Также оптимизировано выполнение запросов с затратной агрегацией данных путем более широкого применения хэшированной агрегации

Ага, т.е. как 10 лет назад будет юзать HashJoin где надо и не надо и валиться по OOM. Приходилось вообще отключать HashJoin в оптимизаторе.

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

Ага, т.е. 10 лет у них ушло на такое решение, чтобы юзать HashJoin где надо и не надо, но по OOM не валиться. Ну помолимся, чтобы они всё-таки им не злоупотребляли.

dimgel ★★★★★
()

Ошибку invalid memory alloc request size в pg_dump устранили или ещё лет пять подождать?

anonymous
()

для миграции данных с версии на версию все еще используются два установленных postgresql?

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

Набежали дурачки с бессмысленными претензиями, создавая информационный шум.

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

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

По такой логике версия вообще не нужна - она же ничего не означает.

Ждём хипстеров с гит-хэшами вместо версий(«а нафига нам версия? а один билд от другого мы и по хэшам отличим!»)

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

По гитхешам нельзя быстро определить какая версия новее (а если исходники недоступны, то всё совсем плохо). По числовой версии (даже если она ушла очень далеко и речь идёт о многозначных числах) - можно. А вот «насколько сильны различия» вопрос уже слишком субъективный и бережное отношение к мажорному номеру версии помогало не так сильно.

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

Ждём хипстеров с гит-хэшами вместо версий

По гитхешам нельзя быстро определить какая версия новее

Эх! Я ж говорю - ждём хипстеров. Ты не похож вроде(хоть аватарку себе поставь с каким-нибудь бородачём в очках на полрожи за просмотром мультфильмов детских).

бережное отношение к мажорному номеру версии помогало не так сильно

И теперь оно вообще не помогает. Причём, легче никому от этого не стало. Мне, конечно, без разницы сама тенденция, но логики в ней я не вижу.

anonymous
()
Ответ на: комментарий от no-such-file

Как будто это что-то плохое.

фанбои и фобы - всегда плохо, если только ты на них не зарабатываешь, но и в этом случае - «фу таким быть» ))

Нафига тебе для OLTP целый SQL, да ещё с процедурами?

Транзакции без процедур (триггеров) и SQL (DML)? Может ещё и ACID в топку?

Я не говорю, что это невозможно, но уже есть готовые к широкому применению альтернативы? Прошлый раз накидали концептов, на которых кто-то что-то делает, но это всё было как раз из разряда «набежали фанбои»…

yyk ★★★★★
()
Ответ на: комментарий от no-such-file

Примерно любой noSQL, не?

если не надо Relational, то на здоровье, но что тебя тогда привело «на огонёк» в тему про RDBMS?

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

COPY — копировать данные между файлом и таблицей

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

slyjoeh ★★★
()
Ответ на: комментарий от no-such-file

«Чукча не читатель, чукча писатель»

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

А можно пример бд, которая так может быстро сделать? Интересно стало.

anonymous
()
Ответ на: комментарий от no-such-file

Оно не надо чуть более чем всегда, окромя аналитики.

Согласен, всяких сайтиков-чятиков и прочей херни в разы больше, чем финансовых и промышленных «асушек», в т.ч. с той самой аналитикой, поэтому чисто статистически они почти не заметны…

Но тебе не кажется, что число применений - не самый главный фактор? ))

И ещё раз: топик про РСУБД, у которых есть устойчивая ниша применения, в которой они пока незаменимы. Чем нам хочет помочь адепт noSQL-я? )

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

Была мода трястись над мажорной версией, не дай бог увеличить

Для тех, кто ни разу ничего сложнее hello world не писал - это не мода, это необходимость.

И в итоге смысла она не несла.

Если обновишь python с 2 на 3 - узнаешь про смысл.

Для тех кто пишет код, который работает в prod годами - смысл есть и будет, и конечно postgresql, java,nginx, kafka,cassadra,spark,flink и тд выпускают минорные обновления.

Chrome (Google)и им подобные - просто не в состоянии выпускать обратно совместимые продукты, по этому и отказались.

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

Ну я так делаю - создаю файл с записями в ФС сервера БД ( можно как угодно - через самбу, NFS, … ) Потом вызываю COPY - всё вставляется на максимальной скорости.

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

Во-первых, речь шла не о поломке API, а о бесполезных компонентах версий. Во-вторых, специально для профнепригодных лентяев: старые версии никто не отбирает. Сидите на своих PY2, PHP3 и PG94 сколько влезет и не вякайте (только поддереживайте их сами, лол).

А те кто пишет код, во-первых, подерживают его актуальность так что он работает с современным ПО, во-вторых хотят использовать и используют все новые фичи. Мы вот выкатили в прод PG13 в среду, и поимели профита с дедубликации индексов. И да, мы мигрировали 50KLOC с py2 на py3. Сделали это за день.

Вы же за сириус бизнес выдаёте галимые шарашки, где код написан один раз, либо студентами за еду, либо разработчиками которые разбежались из этого быдлятника, ну и конечно этот код больше не кому обновлять на новые питоны и базы. Так и будет пердеть на каком-нибудь «стабильном» центосе 6, пока его не поломают, или пока железо не умрёт. Потом бизнес просто загибается. Ну либо оно изначально никому не нужно было.

slovazap ★★★★★
()
Ответ на: комментарий от no-such-file

число применений - не самый главный фактор

ЛУЛ.

мухи?

yyk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.