В ожидании PostgreSQL 15

PostgreSQL 15: Часть 1 или Коммитфест 2021-07

Думаю, вы следите за обзорами Павла Лузанова о новостях коммитфестов. Если нет, то задумайтесь, не стоит ли. Павел, между прочим, не перечисляет буквально все патчи, а отбирает значимые, обычно с SQL-примерами.

Название скромничает: в обзоре также и о PostgreSQL 14 — принятые доработки. Но больше о 15-й. Часто Павел даёт коротенький код, демонстрирующий изменения — в духе «вот так запрос работал в 14-й, а в 15-й уже вот так». Иногда заныривает и глубже в историю — в 13-ю, если это оправдано контекстом, как при анализе pg_dump и схема public, например.

Напоминаем, что самое интересное о 14 версии можно прочитать и в предыдущих статьях: 2020-07, 2020-09, 2020-11, 2021-01 и 2021-03.

Уже начинают появляться заметки «в ожиданиях PostgreSQL 15». Депеш — Hubert 'depesz' Lubaczewski — в первом ряду. В меню его сайта есть отдельный пункт Waiting for (аж со времён 8.4!), и вот в его вейтингах появился пункт меню 15, пока там одинокая заметка:

Waiting for PostgreSQL 15 – Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner.

Это будет важное изменение: раньше не суперюзер по умолчанию мог создавать объекты в схеме public в базе, которой не владел. На то, вроде бы, она и public. Одних устраивало, другие считали это дырой в безопасности. В 15-й всё будет строго.

Права на public по умолчанию обсуждаются и в только что упомянутом обзоре Коммитфеста 2021-07 Павла Лузанова.

Задача о ранце. Теория? Fun? Бизнес?

Она же задача о рюкзаке, она же Knapsack problem. Одна из NP-полных задач. И то, и другое, и третье, конечно.

На этот микрообзор нас спровоцировала недавняя статья:

Solving the knapsack problem in PostgreSQL. Автор Франческо Тизьё (Francesco Tisiot, о нём известно, что он Developer Advocate (!) в финской компании Aiven). Цель вполне скромна: показать возможности программирования с рекурсивным CTE. А также проиллюстрировать, как написать ограничения. Больше ликбез и фан (сначала, до переименования статья называлась «PostgreSQL в помощь пакующим рюкзак для похода на каникулах» — всё же рюкзак, хоть и не backpack).

Но практическая польза задачи о ранце вовсе не скромна: компании вроде Google, Facebook, Amazon наверняка зададут вам на интервью какой-нибудь вопрос, связанный с этим алгоритмом — практичней не придумаешь!

Этим практическая ценность, конечно, не исчерпывается. По актуальности среди NP-полных задач Ренец уступает, разве что Коммивояжёру (дошло до того, что Amazon, не удовлетворённая производительностью доступных суперкомпьютеров с сотнями петафлопсов, проинвестировала в квантовый стартап, который готов ублажить Amazon квантовыми спецрешениями для их софтовых коммивояжёров; но там не до SQL).

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

Российским разработчикам приходилось заниматься решением этой задачи непосредственно по просьбе заказчиков. Причём не на уровне приложения, а внутри базы:

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

Это отсюда: Будни автоматизации или «мне нужна программка для 3D упаковки».

Но почему в базе, а не в приложении?

он [внешний фреймворк] не очень хорошо приспособлен для задач с объемными вычислениями. Обычный цикл у нас выполняется гораздо дольше, чем в компилируемом языке. Поэтому простые, но массовые вычисления бывает удобнее делать на стороне сервера непосредственно на уровне СУБД. Для работы с базой данных у нас используется язык, очень похожий на T-SQL.

Читателям предлагается угадать, о каком языке говорит автор с «Инфософта». Это, мягко говоря, несложно. Она же опубликована и на самом Инфостарте. Это одна и та же статья — и не одна и та же одновременно: в инфостартовском варианте к ней подшиты ещё и комментарии числом 118, в которых — в том числе — автор расписывает детали проекта и обсуждает рациональность использования его решения, а не предложенных неравнодушных читателями альтернативных.

Далее:

Как мы подбирали грузы для перевозчиков

Илья Баштанов (разработчик в «Точка-Точка») и Татьяна Воронова (аналитик данных, «Центр 2М») предлагают реализации жадного алгоритма: на Java (не PL/Java, как я понял) и на PL/pgSQL (то есть опять внутри базы).

Задача отнюдь не демонстрационная: заказчик хотел эффективно загружать транспортные средства (и тем самым увеличить доход от перевозок) и доставлять грузы в приемлемые сроки (включая принцип FIFO).

Решения тестировались: в БД PostgreSQL была подготовлена тестовая таблица, содержащая 7000 грузов со случайными весами от 20 до 800 кг. Для тестирования использовался обычный pgbench, который в процессе теста выполнял 500 транзакций (10 соединений по 50 транзакций). Каждая транзакция делала один вызов алгоритма со случайными параметрами (ограничением на вес от 10 до 1000 кг и на количество грузов от 1 до 50 штук). Все случайные величины распределены равномерно. Интересно, что остановились на PL/pgSQL. Потому, что этот вариант масштабируется немного лучше, видимо, за счёт более скромных требований к оперативной памяти (для хранения промежуточных результатов используются временные таблицы БД). И он с незначительными переделками эксплуатируется заказчиком второй год.

Для разнообразия можно ещё глянуть, скажем, Задача о рюкзаке в контекстной рекламе для досок объявлений — пост на доработке, интересен постановкой задачи — реклама, маркетинг. Или, скажем, Алгоритм решения задачи о рюкзаке (версия 2, исправленная) — исправленная не до конца, но зато с обсуждением (в тексте и комментариях) преимущества и недостатков подходов с жадным алгоритмом (которым воспользовались в соседней статье) и динамического программирования (автор описывает свой подход как усложнение ЖА и упрощение ДП). Решение на псевдокоде. Для любителей зауми.

А вот, наоборот, простенький скрипт на SQL, но использует оракловые KEEP и RANK, которых нет (пока?) в PostgreSQL:
A Simple SQL Solution for the Knapsack Problem (SKP-1) — правда и рюкзак-то здесь 1-мерный (а вот здесь — M-мерный).

Но это лишь 1/1000 часть того, что можно найти о софтверных способах заталкивания в рюкзак различных материальных и нематериальных предметов.

Как устроен Postgres

Запросы в PostgreSQL: 1. Этапы выполнения

Стартовала новая серия Егора Рогова Запросы в PostgreSQL: началось она с этапов выполнения запросов.
За ней последовала статистика. Потом Последовательное сканирование и Индексное сканирование.
Запланированы:
5. соединение вложенным циклом;
6. соединение хешированием;
7. сортировку и соединение слиянием.

Вернёмся к Этапам. Егор подробно разбирает, что происходит по протоколу простых запросов. А затем и по расширенному протоколу — то есть с подготовленными запросами, привязкой значений параметров и уже затем планированием и выполнением.
Статистику Егор разбирает тоже подробно (все статьи довольно большого объёма):

Базовая статистика (неопределенные значения, уникальные значения, наиболее частые значения — MCV).
Гистограмма
Статистика для нескалярных типов данных
Средний размер поля
Корреляция
Статистика по выражению
Расширенная статистика по выражению
Статистика для индекса по выражению
Многовариантная статистика (функциональные зависимости между столбцами, многовариантное число различных значений, многовариантные списки частых значений).

В последовательном сканировании Егор с места в карьер устремляется в будущее PostgreSQL — в подключаемые движки хранения (pluggable storage). С оговоркой: пока доступен только вот этот:

SELECT amname, amhandler FROM pg_am WHERE amtype = 't';
amname |      amhandler 
−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−
 heap   | heap_tableam_handler

Среди некоторого количества разрабатываемых движков Егор выбирает для краткого упоминания два:
Zheap (реализует обновление версий строк на месте и выносит исторические данные, необходимые для построения снимка, в отдельное undo-хранилище -поддержка со стороны EDB).
Zedstore (реализует колоночное хранение — в основном усилиями GreenPlum).

Далее в статье читатель наблюдает этакий лингвистически парадоксальный поворот: разбирая последовательное сканирование уже во вполне привычном контексте, Егор обращается к параллельному последовательному сканированию — не параллельному vs последовательному, а именно так, парадокса на самом деле нет. В финале автор приближается к пределу параллелизма: не всё поддаётся распараллеливанию (например временные таблицы), а что-то и не хочет распараллеливаться, получая пометку PARALLEL RESTRICTED.

Ну а про индексное сканирование уж точно стоит почитать не в моём пересказе. Кроме видов индексного сканирования там есть про оценки стоимости, про INCLUDE-индексы, график сравнения методов доступа. Ну и, конечно, параллельные версии индексного сканирования.

Предыдущие серии Егора:
Изоляция
WAL
Блокировки
Индексы

Планировщики (в смысле шедулеры)

pg_dbms_job v1.0.1

Создал его неутомимый Жиль Дароль (Gilles Darold), который теперь работает в MigOps, и лежит оно на гитхабе компании (последнее время мы нередко ссылаемся на статьи от MigOps, в предыдущем выпуске — Динеш Кумар о производительности Rocky Linux на тестах Phoronix). pg_dbms_job вошло в пакет Ora2Pg. Загружать можно отсюда.

Это новое расширение создано ради совместимости с оракловым шедулером DBMS_JOB. Совместимо со всеми Postgres, начиная с 9.1. Но это не только расширение: ещё запускается демон, имеющий доступ к базе, которую он обслуживает. Он может работать там же, а может и на другом хосте. Такая архитектура выбиралась сознательно. Авторы говорят:
мы выбрали архитектуру с внешним демоном потому, что запускать тысячи подпроцессов от фонового процесса это плохая идея (по умолчанию лимит одновременно работающих заданий 1000).

Сам Жиль Дароль рассказывает, что и зачем они сделали: Одному из наших заказчиков нужна была совместимость с оракловым пакетом DBMS_ERRLOG. Мы создали расширение: pg_dbms_errlog. А для другого заказчика — другое расширение: credcheck, усовершенствующее работу с логинами, правилами, политиками. Но мы рады, что не только заказчики, а пользователи PostgreSQL по всему свету смогут пользоваться свободами PostgreSQL.

Расширение pg_dbms_job можно использовать на DBaaS-платформах Amazon RDS, Aurora, Google Cloud SQL for PostgreSQL и Microsoft Azure Database for PostgreSQL.

Напомним, что в Postgres Pro Enterprise есть мощный pgpro_scheduler, но Enterprise — платная версия. Этот шедулер делался с самого начала без демона, а с фоновыми процессами (backgound workers). Это тоже был осознанный выбор. В документации этот выбор объяснён. По сравнению с внешними планировщиками pgpro_scheduler имеет следующие преимущества:
Любой пользователь может планировать задания независимо.

Планированием заданий можно управлять «на лету», не перезапуская базу данных.

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

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

А недавно Павло Голуб (pashagolub, Cybertec) опубликовал своё сравнение 4 шедулеров:
pg_timetable (Cybertec)
pg_cron (Citus Data)
pgagent (pgAdmin Development Team)
jpgAgent (GoSimple)

Павло сам и разрабатывает pg_timetable. К тому же Павло предлагает вспомнить предыдущие свои публикации на эту тему. Их много.

Статья, видимо, приурочена к выходу версий pg_timetable 4.x.

Только что вышла версия pg_timetable 4.1.0, но радикальные изменения произошли уже в pg_timetable 4.0.0 — настолько радикальные, что она обратно несовместима с версиями 3.x. По ссылке список очень большой, поэтому обещано детальное разъяснение, но на момент нашего обзора там картинка и подпись «этой страницы пока нет». Но можно глянуть документацию.

Ещё статьи

PostgreSQL Custom Dashboards Ported to Percona Monitoring and Management 2

Сергей Кузьмичёв из Percona демонстрирует, как портировать некоторые возможности PMM 1 (Percona Monitoring and Management) в PMM 2. Причем портировать рекомендуется в версию PMM 2.16.0 и выше, так как перконовский postgres_exporter там обновлён до версии 0.8.0 сообщества (о ней можно почитать и на хабре: Новые возможности postgres_exporter для мониторинга PostgreSQL. И, кстати, ещё об экспортерах: pgexporter 0.1.0).

В статье портируются дэшборды PostgreSQL Tuple Statistics и PostgreSQL DB/Table Size Details (разработчик Вадим Яловец). Tuple Statistics кроме прочего показывает соотношение мертвых/живых записей и детали истории вакуумирования. Портируемая версия добавляет информацию о возрасте базы и о том, далеко ли до wraparound, не пора ли запускать вакууум. Диаграммы показывают самые востребованные объекты, опускаясь на уровень отдельных таблиц.

PostgreSQL DB/Table Size Details даёт просто размер таблицы и всей базы, а также скорость роста — очень полезно, когда не ясно, куда девается свободное место на диске.

postgres_fdw Enhancement in PostgreSQL 14

Ибрар Ахмед (Ibrar Ahmed, тоже Percona) демонстрирует достижения в PostgreSQL 14 по части FDW на примерах. И пишет о PostgreSQL FDW. Какой же это Foreign? Это же «свои». Но PosgreSQL FDW используют более, чем часто, на нём можно даже обустроить шардинг.

Иллюстрируя Parallel /Async Foreign Scans, Ибрар создаёт секции от родительской таблицы на 2 внешних серверах, потом вставляет данные в родительскую, и, действительно, мы видим, что в плане появились 2 ветки Async Foreign Scan. В предыдущих версиях они сканировались бы последовательно, а не параллельно. Но для этого опция async_capable, разрешающая параллельное планирование и исполнение ForeignScan, должна быть true.

Далее следует: Bulk Insert теперь работает и в PostgreSQL FDW. Автор (в другой статье) показывает, как это сказывается на времени вставки.

Кроме того Ибрар понемногу говорит и о других новых функциональных фичах:

TRUNCATE разрешено работать на внешних таблицах;
postgres_fdw теперь может импортировать секции, если они прописаны в IMPORT FOREIGN SCHEMA … LIMIT TO;
функция postgres_fdw_get_connections перечисляет открытые соединения по FDW и помечает их валидность;
новая опция keep_connections по умолчанию true, она держит соединения, чтобы последующие запросы могли ими воспользоваться, но когда она выключена, соединения вычищаются после завершения транзакций;
postgres_fdw теперь может, когда надо, восстанавливать соединения, если внешний сервер перезапустился.

PostgreSQL PL/Java – A How-To, Part 1 и 2

Цель у Чарли Батисты (Charly Batista, бразилец, живущий в Китае, а работающий — опять же — в Percona) скромная: он искал в интернете некоторые сведения по PL/Java и пришёл к выводу, что информации-то много, но она либо неполная, либо устаревшая, либо от неё одна путаница; поэтому и решил обобщить свои изыскания в HOWTO и показать, как установить и запустить PL/Java.

Для демонстрации Чарли использует:

PostgreSQL 12.7,
PL/Java 1.6.2,
OpenJDK 11,
Apache Maven 3.6.3

Установив всё, что нужно, Чарли заканчивает часть I кодом, который в качестве результата возвращает нам респа Робина Хейса, зачем-то помещённого Чарльзом в город Елец Липецкой Области. А вот обещанный total автор зажал: функция есть, а вызова её нет. Бог ему судия. Во всяком случае, проштудировав многочисленные примеры, читатель научится:

получать доступ к объектам;
крутить цикл по результатам;
упаковывать результаты в массивы и DataSet;
делать что-то с результатами до того, как они будут возвращены (в примере показано, как анонимизировать данные);
создавать триггер с PL/Java-функциями.

Это по сумме 1-й и 2-й частей. В 3-й, ещё не вышедшей части PL/Java будет обращаться к внешним источникам данных.

Продолжение серии о Empire ERP

В прошлом выпуске было о статьях начала серии Empire ERP. Занимательная бухгалтерия, в том числе Занимательная бухгалтерия: PostgreSQL. Сейчас в серии 4 статьи, и смотреть их удобней не на Хабре, а на Гитхабе: там и «содержание» — ссылки на все статьи (сейчас их 4). Там же и недавняя — Аналитический учет, ч.1. Виноват, уже 5: появилась 2-я часть.

Автор обещает и будущие софтверные приключения с питонным уклоном: сейчас рассматривается стэк технологий: PostgreSQL, SQLAlchemy, FastAPI, Svelte/Material. А разворачиваться на десктопы это будет с помощью Ansible.

Что такое Open Source, и с чем его едят в наше время

В этой статье зам. гендира Postgres Professional Ивана Панченко на tadviser нет ни одного вхождения слова PostgreSQL. Но прочитать её стоит. Так уж вышло, что в этом выпуске Иван выступает в трёх амплуа: специалиста по внутренностям Postgres, астронома (см. ниже) и — вот в этой статье — говорит об open source. Но не сладкие слова о свободном мире свободных разработчиков с их свободном кодом, а о разнице open source vs. free software; о хеллоуиновских документах; SSPL, по которой распространяются Mongo DB и Elasticsearch; что к 2021-му open source и коммерческое ПО — более не два разных враждующих лагеря, а два способа разработки, дополняющие друг друга и занимающие свои ниши. И даже предлагает новое понятие: open design — когда не только сами коды открыты, но и документы, объясняющие внутреннее устройство системы, обязательно присутствуют и тоже открыты. А в конце ещё и полемизирует с тезисами Минцифры.

Скандал в благородном семействе

Действительно благородном, без кавычек: участники его — с одной стороны Альваро Эрнандес (Álvaro Hernandez Tortosa, OnGres), с другой — всё сообщество PostgreSQL, представленное Core Team, то есть командой, которая де факто решает все важнейшие стратегические вопросы проекта.

Альваро Эрнандес (фото из материалов конференции PGConf.Russia)

Альваро знают как важного разработчика — он больше 20 лет занимается Postgres, разработчик JDBC-драйвера и многого другого, он часто выступает на постгресовых конференциях, в том числе на PG.Day и PGConf.Russia — с ним приятно и полезно побеседовать в кулуарах и/или на фуршете. Кроме того он основатель и президент Fundación PostgreSQL — НКО-ассоциации испаноязычных постгресистов, для которой он и старался.

У истории с попытками регистрации в ЕС и в США торговой марки PostgreSQL и Postgres, докатившейся аж до Российских СМИ, есть предыстория: Альваро — настоящий революционер. Почти год назад — когда EDB поглотила 2ndQuadrant — он призывал радикальным изменениям в руководящих структурах проекта, тогда же предложил разобраться с правовой основой торговых марок, а ещё озаботился гендерным и расовым балансом (мол, в руководстве слишком высок % белых ЦИС-гендерных мужчин, нужны квоты). Большинство было против хотя бы по последним пунктам по принципу «не буди лихо, пока оно тихо» (почитайте комментарии под воззванием Альваро). Но и по остальным пунктам мало кто был за изменения в механизме, где всё и так до сих пор неплохо работало. Воззвание начиналось со слов «Не пора ли..» — тогда было точно не пора. Мы этой ситуации посвятили полдюжины абзацев Постгрессо 26 (главка «Пополнение в Core Team»).

Альваро воспользовался тем, против чего он, пожалуй, боролся: зазором между формальной, юридической стороной управления копирайтами и торговыми марками (ими рулит юрлицо Postgres Association of Canada) и целой системой из неформальных, нигде не прописанных, подразумеваемых договорённостей, на которых во многом держится и движется вперёд всё сообщество во главе с PostgreSQL Core Team. В прошлом году Альваро вопрошал: а если PGAOC надоест подчиняться сообществу? В 2021 ему самому надоело подчиняться, и он просто начал регистрировать торговые марки сам. Начал с Испании, и это сошло с рук. Но (по его словам, которым лично я верю) всё не корысти ради, а дабы не уплыли они из-под сообщества, остались в надёжных руках идейного борца с централизованным и непрозрачным управлением интеллектуальной собственностью.

Стороны обменялись нетипично резкими заявлениями: Trademark Actions Against the PostgreSQL Community vs. Postgres Core Team launches unprecedented attack against the Postgres Community. После чего Альваро многословно оправдывался и объявил, что начал процесс передачи PGAOC всех торговых марок и доменных имён, связанных с PostgreSQL.

Релизы

Релизная группа (Эндрю Данстан (Andrew Duntan), Мишель Пакье (Michael Paquier) и Питер Гайген (Peter Geoghegan) — Release Management Team) разослала график выхода главных релизов:

PostgreSQL 14 релиз-кандидат (RC1) должен выйти 23 сентября.
UPDATE: Релиз-кандидат вышел. В нём выделили 4 пункта как самые важные:
— autovacuum, анализирующий секционированные таблицы отозван и не попадёт в PostgreSQL 14.
— EXPLAIN VERBOSE заработал в запросах с SEARCH BREADTH FIRST.
— CREATE STATISTICS теперь отказывается работать в выражениях с одной переменной.
— SELECT DISTINCT ROW больше не выдаёт ошибку.

Общедоступный (generally available) PostgreSQL 14 должен выйти 30-го сентября, если не будут обнаружены критичные баги. Говорят, особых проблем не предвидится.

pgBadger v11.6

В этой версии pgBadger, вышедшей после перерыва в полгода, есть некоторые (не слишком радикальные) усовершенствования. Например:

Автоматическое определение Query Id в log_line_prefix для PG14.
Более продвинутые регрессионные тесты с возможностью исключения заданной базы данных; с включённой опцией --explode. Компания MigOps помогла патчем (ещё бы: Жиль Дароль, автор pgBadger, там теперь работает).
Ещё один их патч: теперь можно использовать параллельные процессы при генерации отчёта, когда включена опция --explode.
Добавлена опция --iso-week-number в инкрементальном режиме. Теперь в календаре неделя сможет начинаться с понедельника! Номера недель теперь соответствуют ISO 8601 — от 1 до 53.
--iso-week-number скорее всего станет дефолтным в следующем мажорном релизе, а тогда --start-monday удалят за ненадобностью, и неделя [ура!] всегда будет начинаться с понедельника, с воскресеньями в начале недели будет покончено.
Теперь pgBadger стал совместим с лог-файлами Postgres Pro (в том числе номера записей и размеры в байтах после цифры продолжительности запроса).

Psycopg 3.0 beta 1

Прекрасная новость! В том числе потому, что приятно видеть «русский след» в софте, который вызывает немалый интерес у разработчиков. Ныне лондонский итальянец Даниэль Варраццо (Daniele Varrazzo), лидер проекта Psycopg 3 (он ещё и прекрасный фотограф — have fun) — выражает особенную благодарность Postgres Professional, Command Prompt (США) и многим другим компаниям и разработчикам-энтузиастам.

Полное имя — psycopg-pool 3.0b1. Psycopg 2 полностью переписали, оставив ту же архитектуру с обёртками для libpq (wrapper architecture) и интерфейсом DB-API, но добавили новые фичи, которые будут лучше работать с новыми версиями Python и PostgreSQL.

Со стороны Python новое, например, в том, что можно использовать параллельные и статические типы на базе асинхронного ввода-вывода — asyncio (а о connection pool в Psycopg 3 будет чуть ниже).

Со стороны PostgreSQL Psycopg 3 теперь может использовать серверные параметры, подготовленные запросы, двоичные параметры и отличную поддержку операций COPY. Ещё интересные подробности есть здесь и в блоге Даниэля: здесь и здесь.

Чтобы установить, зайдите сюда.

И вот статья о psycopg3 в блоге rustprooflabs: Psycopg3 Initial Review. Райан Лэмберт (Ryan Lambert, владелец и гендир RustProof Labs) особенно заинтересовался обещанным прогрессом в работе пула соединений (в Psycopg 3 за него отвечает опциональный пакет psycopg_pool) и решил его потестировать. Клиентское приложение на своём ноутбуке, а сам Postgres на ARM — Raspberry Pi 4 с данными на USB3 SSD-диске. Связь по бытовому WiFi. Нагрузка симулируется на Саранче — Locust. Он симулировал до 70 одновременных пользователей. На графиках видно, что при таком количестве пользователей с пулом производительность масштабируется, а без него — нет. Время ожидания сокращается в 3 раза. В статье выводов особых и нет: мы ждали улучшений, и дождались — даже в бете.

postgresql-wheel

Это сервер PostgreSQL, который весь умещается в пакете Python package уже в скомпилированном виде и устанавливается как один pip-файл:

$ pip install postgresql-wheel

Все серверы запускаются как локальные Python-процессы, ни root, ни sudo не нужно, и запускать можно в любом каталоге. И внешних зависимостей нет. Очень удобно для тестирования. Но есть пока только версии для основных Linux. Автор — Мишель Пеллетье (Michel Pelletier).

WAL-G 1.1

Новое, касающееся PostgreSQL:

wal-verify теперь можно запускать на реплике;
wal-verify теперь игнорирует постоянные бэкапы (permanent backups).

А также:

В релизы на GitHub включена библиотека шифрования libsodium. WAL-G должна быть скомпилирована с ней.
UserData теперь должна быть валидным JSON.
backup-list теперь сортирует бэкапы по астрономической дате завершения.

pgmoneta 0.5.0

Дэвид Феттер (David Fetter), почти коллега: составляет списки новостей. Он, вместе с Яспером Педерсеном (Jesper Pedersen) и
Уилом Линвебером (Will Leinweber) участник проекта pgmoneta. Это решение для резервного копирования / восстановления. По молодости своей оно не входит в список на PostgreSQL.org, но кое-что умеет.

В этой версии появились:
поддержка failover;
политики, где копий хранятся дольше, чем окно сохранения (retention window);
поддержка всех настроек recovery_target. Инструкции по установке и настройке есть на гитхабе.

PGSpider

Это расширение для конструирования высокопроизводительных кластеров распределённых больших данных. Может обращаться к разным источникам, работает через FDW. Возможно, заслуживает более подробного обсуждения в будущих выпусках Postgresso. Разрабатывают его в Toshiba Software Engineering & Technology Center.

Ещё о релизах — в 2 словах

PostGIS 3.1.4, 3.0.4

Исправлены баги. Эта версия работает с PostgreSQL 9.6-14. Загрузить можно отсюда.

AGE 0.5.0 и 0.6.0

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

pgagroal 1.3.0

Новое в этом пулере: дэшборд Grafana 8; новые метрики Prometheus в разделах клиент, пулинг и внутренние.

pg_dumpbinary-v25

Утилита научилась восстанавливать данные таблиц с изменявшейся структурой.

set_user 2.0.1

Расширение, которое даёт возможность эскалировать привилегии с усовершенствованным логированием и управлением. Эта минорная версия закрывает дыру в безопасности.

pglogical 2.4.0

Исправлены баги. Загружать отсюда.

pg_msvc_generator 1.0.0 beta

Инструмент для создания версий для Windows у расширений. Представляет собой 2 перловых скрипта.

Crunchy PostgreSQL Operator 5.0.2

Поддержка новых версий PostgreSQL, TimescaleDB 2.4.0 (вышли и 2.4.1, и 2.4.2, но там исправлены баги), set_user 2.0.1. Главные изменения произошли до этого — в Crunchy PostgreSQL Operator 5.0.0.

pgAdmin 4 v5.6

Из изменений:
можно копировать SQL из главного окна в окошко запросов;
стало удобней просматривать, форматировать и редактировать JSON.

pgbouncer 1.16.0

Появилась, например, горячая перезагрузка конфигурации TLS. Загрузить можно отсюда.

dbForge Data Compare for PostgreSQL v3.4

В новой версии можно работать с IBM Cloud и с Amazon Aurora. Можно попробовать: доступна пробная 30-дневная версия.

pgdiff

Утилита, которая показывает, что изменилось в Postgres-базе между 2 заданными моментами времени.

PL/Julia

Расширение для языка Julia внутри PostgreSQL. Презентация Джулии.

Конференции, митапы, Вторники

SaintHighload++ 2021
Только что — 20-21 сентября — закончилась (Saint в данном случае не святой, а питерский Highload++). Были в том числе постгресовые доклады:
Анатолий Афиногенов (ВНИИЖТ) Миграция приложения Oracle PL/SQL на Postgres pl/pgSQL: планирование, подготовка, переход и два года жизни с новой БД;
Олег Бартунов и Никита Глухов (оба Postgres Professional) Json or not Json. Плюсы и минусы использования Json в PostgreSQL;
Николай Ихалайнен (Percona) Симуляция боевой инсталляции MySQL/ MariaDB/ Postgresql/ MongoDB;
Алексей Лесовский (Data Egret) Что нового в плане мониторинга в PostgreSQL.
И на другие любопытные темы, например:
Егор Гришечко (Uber, изменившая Постгресу с MySQL) Stateful Deployment Platform или как Uber управляет сотнями тысяч баз данных Архитектуры, масштабируемость
Михаил Голубев (AWS) и Дмитрий Иванов (IPONWEB) Как (и зачем) переехать на архитектуру ARM в облаке?

PGConf.NN

Нижегородская конференция-митап PGConf.NN состоится в оффлайне уже 30 сентября в нижегородском Технопарке «Анкудиновка». Организаторы – Postgres Professional и ассоциация IT-компаний iCluster.
В программе доклады о
хранении документов формата JSON в PostgreSQL,
обеспечении надёжного резервирования и хранения данных в Postgres и о
преимуществах SQL и NoSQL СУБД.

Параллельно с ней 30 сентября будет опробована выездная сертификация PostgreSQL DBA — выездное тестирование администраторов СУБД PostgreSQL с выдачей сертификата Программы профессиональной сертификации. Место проведения тестирования — коворкинг Vmeste (Ул Белинского 63, ТЦ «Этажи»,5 этаж, конференц-зал). Записаться на тестирование можно здесь, выбрав при записи площадку «Нижний Новгород». Начало в 10.00.

PGConf.Russia 2021

Состоится 25 – 26 октября в Москве, на этот раз в Первом МГМУ имени И. М. Сеченова. Регистрация и заявки на доклады принимаются, вот рекомендованные темы:

PostgreSQL на переднем крае: большие данные, интернет вещей, блокчейн.
новое в PostgreSQL и вокруг: развитие PostgreSQL и его экосистемы.
PostgreSQL в реальных системах: архитектура, миграция, эксплуатация.
Использование PostgreSQL в платформе 1С.
PostgreSQL в геоинформационных системах (GIS).

SECON 2021

Конференция состоялась 19-20 июня на территории базы отдыха «Арт-Пенза» и скульптурного парка «Легенда». Постгресовую тематику представлял Иван Панченко с докладом Использование JSON в PostgreSQL — о различных паттернах использования JSON и о средствах для работы с ним, предоставляемых PostgreSQL.

Это была немного облегчённая версия. Более углублённо, для более специализированной аудитории Иван делал примерно на эту тему мастер-класс на PGConf.Russia 2020. Он доступен в слайдах и в видео.

Но постгресовой тематикой Иван отнюдь не ограничился. Ещё один доклад назывался Астроликбез для айтишников — какие связи есть между айти и астрономией, авторская версия FAQ по астрономии:

Астрономия — это наука о данных. Астрономы всегда первыми учились работать с большими данными, со статистикой, и с компьютерными технологиями. Потому что они всегда жили в условиях дефицита данных. К черной дыре не подойдешь со штангелем, приходится учиться делать достоверные выводы по недостаточным и неточным данным.

Лекция пользовалась успехом, и Иван рассказал об ИТ-астрономии и на SaintHighload++. А ещё дарил самым активным участникам обсуждения книжку: Киричек, Панченко: Неизвестное Солнце. Расследование. Чудеса. Факты. Загадки

Вообще тематика конференции пёстрая. И бизнес, и технологии, и про гиперказуальные игры, и про ИИ, конечно. Был и такой, например, доклад: начальник отдела разработки в МЦСТ Сергей Юрлин посвятил в уровень и перспективы платформы Эльбрус. Показал типоряд микропроцессоров и вычислительных панелей платформы Эльбрус, кратко описал маршрут проектирования и варианты сотрудничества.

Теперь о Постгрес-ВТОРНИКАХ. В этом сезоне их было 3:

Постгрес-вторник 2021-09-14: «DIY OKметер»: netdata, pgwatch2 — открытые и перспективные системы мониторинга

Постгрес-вторник 2021-09-07: долгие запросы, длинные транзакции

Постгрес-вторник 2021-08-24: «Субтранзакции прокляты»

Ссылка на файл, где темы и планы на будущее.

Книги

Оптимизация запросов PostgreSQL

Книга Генриэтты Домбровской, Бориса Новикова и Анны Бейликовой. Книга выходит в ДМК Пресс. Это перевод, оригинал PostgreSQL Query Optimization. The Ultimate Guide to Building Efficient Queries был издан Apress в этом году. Авторы так предваряют книгу:

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

PostGIS in Action, Third Edition.

Книжка вышла в Manning Publications. У них есть и страничка в фейсбуке.

На сегодня, кажется, всё. До встречи примерно через месяц!

Postgresso 34