Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Новости

Главное событие месяца — это, конечно, Feature Freeze. Мартовский коммитфест закрыт. Основной облик версии PostgreSQL 12 определился. Дальше будут доработки и исправления, но не изменения в функциональности. О наиболее важных фичах 12 версии в ближайшее время мы сделаем отдельную публикацию.

Уязвима ли «уязвимость»

Под загадочным кодом CVE-2019-9193 скрывается политически важная для сообщества причина беспокойства. Речь о конструкции COPY… PROGRAM, появившейся еще в 9.3, которая дает возможность исполнять в запросе файлы ОС и писать в стандартный ввод или читать из стандартного вывода программы.

When a vulnerability is not a vulnerability

Однако, классик PostgreSQL Магнус Хагандер (Magnus Hagander) разъясняет в своем блоге:
Эта «уязвимость» эквивалентна тому факту, что в типичной Unix-системе вы можете залогиниться рутом и создавать или редактировать файлы, и исполнять команды как root. <...> Будучи суперюзером, можно запускать файлы в ОС отнюдь не только при помощи COPY… PROGRAM." <...> Итак, уязвимости в PostgreSQL нет, зато однозначно есть уязвимые инсталляции PostgreSQL.

Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции PGConf.Russia 2019. В первой части доклада Ивана Фролкова речь шла о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. В этой части вас ждет разбор обработки ошибок, конкурентного доступа, неотменяемых операций, CTE и JSON.



Расскажу такую историю. Наш клиент говорит: «Медленно работает база, а наше приложение занимается обслуживаем населения. Мы боимся, что нас тут поднимут на вилы». Выяснилось, что у них было очень много процессов в состоянии idle in transaction. Приложение начало транзакцию, ничего не делает, но и транзакцию не завершает. Если вы взаимодействуете с какими-то внешними сервисами, то, в принципе, это нормальная ситуация. Другое дело, что если у вас состояние idle in transaction длится долго (больше минуты уже подозрительно), то это плохо потому, что PostgreSQL очень не любит долгие транзакции: VACUUM не сможет почистить все те строки, которые он мог бы увидеть, и долго висящая транзакция эффективно блокирует VACUUM. Начинают разбухать таблицы, индексы становятся всё менее эффективными.

Чуть более месяца назад в Москве состоялась крупнейшая конференция постгресового сообщества PGConf.Russia 2019, собравшая в МГУ свыше 700 человек. Мы решили выложить видео и расшифровку лучших докладов. Выступление Ивана Фролкова с разбором типичных ошибок при работе с PostgreSQL было отмечено лучшим на конференции, поэтому мы начнем с него.

Для удобства мы разбили расшифровку на две части. В этой статье речь пойдет о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. Во второй части будут разобраны обработка ошибок, конкурентный доступ, неотменяемые операции, CTE и JSON.



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

Главный вывод, который я смог сделать из того, что я видел, довольно неожиданный: фактически любое приложение при должной настойчивости можно заставить работать. Был замечательный проект (я не могу упоминать все компании, с которыми мы работали), в котором еще более замечательное приложение создавало таблицы миллионами. Выглядело это так: в понедельник система работает неплохо, а уже в пятницу она практически не работает. На выходные дни запускают VACUUM FULL, и в понедельник она опять работает хорошо. Оказывается, над PostgreSQL можно вот так издеваться, и всё это довольно долго будет жить и работать. Другой товарищ сделал странную вещь: у него всё было построено на триггерах, процедур не было вообще. То есть большую часть таблиц трогать нельзя, сделать что-либо не получалось, но и эта база жила.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Новости

Microsoft приобрела Citus Data

Безусловно, главная новость в мире PostgreSQL. Об этом есть сообщение на сайте Citus, равно как и на сайте MS.

Postgres Pro Enterprise Certified

СУБД Postgres Pro Enterprise получила сертификат ФСТЭК, и теперь в наборе Postgres Pro есть и «Сертифицированная версия Postgres Pro Enterprise». До этого сертификат, необходимый для работы с персональными данными, имела только Postgres Pro Standard («Сертифицированная версия Postgres Pro»). Подробности на сайте.

credativ: PostgreSQL Competence Center

Германская фирма credativ, до того известная в Европе и Азии, приобрела фирму OmniTI, чтобы выйти на американский рынок. credativ специализируется на развертывании и поддержке проектов open source. Теперь в США откроется PostgreSQL Competence Center, который будет заниматься высококритичными проектами и поддерживать БД в течение всего их жизненного цикла.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL. В этом предновогоднем выпуске не будем утомлять вас длинным перечнем новостей. С Наступающим Новым Годом!

Релизы

pgAdmin4 3.6

В этой версии добавлены:

• из панели Properties можно дропать несколько объектов одновременно;
• можно импортировать из и экспортировать в определения серверов из базы и в базу данных конфигураций.

pgpoolAdmin 4.0.2

Можно скачать здесь, как и многочисленные предыдущие версии.

dbForge Studio for PostgreSQL v2.0

На этот раз devart выпустила Studio со Standard edition, в которой есть функциональность, не включенная в бесплатную версию Express. 30 дней можно пользоваться Standard edition бесплатно. О различиях Standard и Express можно почитать здесь.

VOPS-2.0

Вышла новая версия расширения PostgreSQL от Postgres Professional для эффективного исполнения векторных операций.

pg_probackup 2.0.25

Новая версия утилиты для бэкапа и восстановления, тоже от Postgres Professional

pgCluu 2.9

Новую версию этой программы на Perl для аудита производительности кластеров с PostgreSQL можно скачать здесь. pgCluu собирает статистику работы не только СУБД, но и системные ресурсы кластера.

postgres_dba 4.0

Вышла новая версия утилиты Николая Самохвалова для администрирования PostgreSQL. В ней появились три новых отчета: список расширений, настройка параметров PostgreSQL и Вакуум: что происходит прямо сейчас. И, конечно, доработки и исправления.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Релизы

PostgreSQL 11.1
Вместе с этой версией вышли также 10.6, 9.6.11, 9.5.15, 9.4.20 и 9.3.25 (это последний релиз 9.3). В этой версии есть изменения, связанные с безопасностью. Исправили выявленные ошибки. Прочитать о релизах можно здесь, а скачать здесь.


Postgres Pro Standard 11.1.1, 10.6.1, 9.6.11.1, 9.5.15.1, Postgres Pro Enterprise 10.6.1, 9.6.11.1

Эти релизы основаны на соответствующих ванильных версиях PostgreSQL и на предыдущих версиях Standard и Enterprise. В разделе «Замечания к выпуску» в соответствующей версии документации можно прочитать об отличиях от предыдущей версии семейства. Например, в Enterprise 10.6.1 и 9.6.11.1 добавлена поддержка операционной системы Astra Linux «Смоленск» 1.6 и улучшена стабильность автономных транзакций.

pgAdmin 4 version 3.5.

В этом релизе не только исправлены баги (11 штук), но и добавлены новые возможности. Среди них:

• Миграция с Bootstrap 3 на Bootstrap 4
• Можно останавливать сервисные процессы (Backup/Restore/Maintenance...)

Бинарники для Windows и macOS, а также для Python Wheel, Docker-контейнеры и тарболы с исходниками можно скачать отсюда. RPMы и DEBы должны появиться в репозиториях postgresql.org в ближайшие дни.

TimescaleDB 1.0

В анонсе говорится, что это версия годится для использования в промышленном режиме. Эта СУБД, ориентированная на работу с временнЫми рядами, выполнена как расширение для PostgreSQL. Можно запускать разные версии TimescaleDB с одним и тем же экземпляром PostgreSQL Ядро команды разработчиков — выпускники Принстонского Университета.

Часть I. R извлекает и рисует

Конечно, PostgreSQL с самого начала создавалась как универсальная СУБД, а не как специализированная OLAP-система. Но один из больших плюсов Постгреса — в поддержке языков программирования, с помощью которых из него можно сделать что угодно. По изобилию встроенных процедурных языков ему просто нет равных. PL/R — серверная реализация R — любимого языка аналитиков — один из них. Но об этом позже.

R – удивительный язык со своеобразными типами данных — list, например, может включать в себя не только данные разных типов, но и функции (вообще, язык эклектичный, и говорить о принадлежности его к определенному семейству не будем, чтобы не порождать отвлекающие дискуссии). В нем есть симпатичный тип данных data.frame, который подражает таблице РСУБД — это матрица, у которой столбцы содержат разные типы данных, общие на уровне столбца. Поэтому (и по другим причинам) работать в R с базами данных довольно удобно.

Мы будем работать в командной строке в среде RStudio и соединяться с PostgreSQL через драйвер ODBC RpostgreSQL. Их несложно установить.

Поскольку R создавался как этакий вариант языка S для тех, кто занимается статистикой, то и мы приведем примеры из простенькой статистики с простенькой графикой. У нас нет цели знакомить с языком, но есть цель показать взаимодействие R и PostgreSQL.

Обрабатывать данные, хранящиеся в PostgreSQL, можно тремя путями.

Специальный выпуск POSTGRESSO, посвященный выходу официального релиза версии 11.

---

На улице PostgreSQL праздник. После четырех beta вышла PostgreSQL 11 General Availability, то есть официальная версия. В анонсе есть даже приветственное слово Брюса Момджана: «готовя этот релиз, сообщество особенно заботилось о добавлении функциональности, необходимой для работы с очень большими базами данных. Доказано, что PostgreSQL хорошо работает с транзакционными нагрузками, а теперь новая версия — PostgreSQL 11 — облегчит разработчикам еще и создание приложений для Big Data».

В release notes выделяют

• секционирование:
  • добавлено секционирование по хешу;
  • PRIMARY KEY, FOREIGN KEY, индексы (см. ниже на эту тему) и триггеры;
  • секция по умолчанию для записей, вышедших за границы созданных секций;
  • UPDATE по ключу секционирования теперь может автоматически перемещать запись в соответствующую секцию;
  • PostgreSQL научился исключать ненужные секции (partition pruning) во время исполнения запросов SELECT;
• распараллеливание:
  • теперь можно параллельно создавать индекс в случае B-tree;
  • при CREATE TABLE… AS, CREATE MATERIALIZED VIEW и в некоторых случаях запросов с UNION;
  • улучшена производительность в параллельных HASH JOIN и SEQUENTIAL SCAN;
• появились хранимые процедуры, и в них возможно управление транзакциями;
• JIT-компиляция фрагментов запросов, выигрыш на вычислении выражений;
• оконные функции теперь поддерживают все фреймовые опции SQL:2011 стандарта, в том числе расстояния по RANGE у PRECEDING/FOLLOWING, режим GROUPS, возможность исключения строк из фрейма;
• появились покрывающие индексы [не покрывающие, а инклюзивные, строго говоря — прим. POSTGRESSO], использующие выражение INCLUDE при CREATE INDEX;
• из раздела «разное»: ALTER TABLE… ADD COLUMN c значениями NOT NULL по умолчанию: этот вариант команды теперь не перезаписывает все строки таблицы и, следовательно, работает быстро.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Релизы

PostgreSQL 11 Beta 4
В этом релизе починили баги, выявленные после выхода Beta 3. В том числе:

• теперь отключена по умолчанию JIT-компиляция.
• имена в constraint-ах должны быть уникальны.
• убрали утечку памяти при обращении к XMLTABLE
• исправили ошибки в хранимых процедурах
• доработали секционирование, в том числе выбор секций в момент исполнения (runtime partition pruning)

Подробнее здесь.

PostgreSQL 10.5
В этом релизе несколько десятков исправлений, касающихся WAL, libpq, VACUUM и FREEZE, индексов GIN, распараллеливания запросов, OpenSSL. Вот их список.

Postgres Pro Enterprise 10.5.2.
В этой версии есть следующие нововведения по отношению к Postgres Pro Enterprise 10.5.1, они касаются pgbench:

• pgbench теперь поддерживает составные команды;
• с помощью параметра --latency-limit теперь можно ограничить время, отведённое на повторение транзакций. Если при использовании данного параметра значение --max-tries=0, транзакции могут повторяться неограниченное число раз, пока не истечёт время, заданное параметром --latency-limit;
• при вычислении количества обработанных транзакций и скорости выполнения (TPS) пропущенные и неуспешные транзакции больше не учитываются.

Напомним, за время между нашими выпусками вышел релиз Postgres Pro Enterprise 10.5.1.. Там есть существенные изменения, о них можно прочитать здесь.

Масштабирование СУБД – это непрерывно наступающее будущее. СУБД совершенствуются и лучше масштабируются на аппаратных платформах, а сами аппаратные платформы наращивают производительность, число ядер, памяти — Ахиллес догоняет черепаху, но все еще не догнал. Проблема масштабирования СУБД стоит во весь рост.

Компании Postgres Professional с проблемой масштабирования довелось столкнуться не только теоретически, но и практически: у своих заказчиков. И не раз. Об одном из таких случаев и пойдёт речь в этой статье.

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

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL. Между этим выпуском и #8 прошло больше времени, чем обычно, поэтому он будет более объемным.

---

Релизы

PostgreSQL 11 Beta 3
Этот релиз отличается исправленными багами — и общими для серии релизов, о которых дальше, и специфическими для версии 11. Подробности об исправленных (и не только) багах можно узнать здесь. Общая информация о beta здесь.

PostgreSQL 10.5
Исправлены серьезные баги. Например, обнаружена и исправлена проблема в libpq: она не восстанавливала в начальное состояние все переменные состояния соединения при попытке повторного соединения. Не восстанавливалась переменная, которая задавала, нужен ли пароль, из-за чего, используя dblink или postgres_fdw, можно было получить незаконный доступ к серверам.
Всего в релизе около 20 исправлений и улучшений, касающихся самых разных механизмов СУБД: VACUUM, WAL, GIN-индексы, POSIX-семафоров и многого другого. В том числе для работы под Windows. Они расписаны тут.

Вместе с 10.5 и Beta 3 вышли соответствующие обновления 9.6.10, 9.5.14, 9.4.19, 9.3.24. Скачать можно, как обычно, отсюда.

Postgres Pro Standard 9.5.14.1, 9.6.10.1 и 10.5.1
Релизы Postgres Pro Standard 9.5.14.1 и 10.5.1 созданы Postgres Professional на базе соответствующих версий PostgreSQL (без последней цифры в номере релиза, напр PostgreSQL 10.5) и соответствующих предыдущих версий Postgres Pro Standard.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Слоны

Саймон Риггс, глава 2ndQuadrant, призывает компании поучаствовать в защите слонов, в том числе сообщая о случаях онлайновой торговли слоновой костью.

Релизы

PostgreSQL 11 Beta 2 Released
Выход этого релиза в том числе связан с обнаруженной проблеме со SCRAM. В Beta 1 появилась мажорная фича Channel Binding for SCRAM Authentication (привязка канала) для предотвращения атак с «человеком посередине» (man-in-the-middle). Но при тестировании выяснилось, что libpq не в состоянии гарантировать channel binding. В Beta 2 сама фича не удалена, но удалена документация к ней, а фича потеряла статус мажорной.Подробней о релизе можно прочитать здесь, а скачать Beta 2 можно здесь.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Релизы

Как и обещано, бета-версия PostgreSQL 11 вышла 25-го мая. Ее новшества по отношению к 10.х в основном уже перечислены в сводке Что заморозили на feature freeze.

Postgres Pro 10.4.1
Компания Postgres Professional выпустила новые релизы Postgres Pro Standard/Enterprise 10.4.1, созданные на базе PostgreSQL 10.4 и Postgres Pro 10.3.2. В них вошли все улучшения версии PostgreSQL 10.4, а также ряд важных доработок:

• обновлён модуль jsquery, отвечающий за запросы к типу данных jsonb;
• утилита pg_probackup для управления резервным копированием и восстановлением кластеров баз данных обновлена до версии 2.0.17 и дополнена новыми возможностями; например, добавлен режим DELTA, в котором считываются все файлы данных в каталоге и создаётся инкрементальная копия для страниц, изменённых со времени предыдущего копирования;
• модуль pg_pathman, отвечающий за секционирование больших и распределённых баз данных, обновлён до версии 1.4.11, в которой исправлен ряд ошибок;
• исправлена сортировка букв «Ё» и «Й» в модуле mchar, предоставляющем дополнительные типы данных для совместимости с Ms SQL Server;
• доработана версия для Windows.

Несколько недель перед важным комитфестом — последним перед feature freeze версии PostgreSQL 11 — читатели рассылки hackers, сжимая в левой пакет с чипсами, следили за триллером MERGE. Режиссер триллера, глава компании 2ndQuadrant Саймон Риггс (Simon Riggs), с впечатляющей настойчивостью и изобретательностью пытался протащить в версию патч, реализующий синтаксис команды MERGE. Риггс комитер с 2009 года, а со статусом комитера можно самому утверждать патчи. Ему противостояли не менее уважаемые комитеры и ветераны PostgreSQL. Страсти кипели явно и подспудно, до прямых оскорблений все же не дошло — факт удивительный для завсегдатаев многих отечественных форумов. Однако некоторое напряжение осталось до сих пор, когда вопрос утрясли, и спорить уже не о чем.

Представьте ситуацию. Субботний вечер. Вы — администратор PostgreSQL, после тяжелой трудовой недели уехали на дачу за 200 км от любимой работы и чувствуете себя прекрасно… Пока Ваш покой не нарушает смс от системы мониторинга Zabbix. Произошел сбой на сервере СУБД, база данных с текущего момента недоступна. На решение проблемы отводится короткое время. И Вам ничего не остается, как с тяжелым сердцем оседлать служебный гироскутер и мчаться на работу. Увы!


А ведь могло быть по-другому. Вам приходит смс от системы мониторинга, что произошел сбой на одном из серверов. Но СУБД продолжает работать, поскольку отказоустойчивый кластер PostgreSQL отработал потерю одного узла и продолжает функционировать. Нет надобности срочно ехать на работу и восстанавливать сервер БД. Выяснение причин сбоя и работы по восстановлению спокойно переносятся на рабочий понедельник.

Как бы то ни было, стоит подумать о технологиях отказоустойчивы кластеров с СУБД PostgreSQL. Мы расскажем о построении отказоустойчивого кластера СУБД PostgreSQL с помощью программного обеспечения Pacemaker&Corosync.

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL.

Релизы

PostgreSQL 11 Beta
Релизная команда PostgreSQL определилась с датой выпуска бета-версии: 24 мая 2018.

Вышел PostgreSQL 10.4

В отличие от версии 10.3, которая была внеплановой (нужно было срочно закрыть важные дыры в безопасности), эта версия вышла в соответствии с графиком.
В новой версии много поправок. Из заплаток, привлекших внимание: излишне либеральный доступ (ACL) к функции pg_logfile_rotate(); ослаблены блокировки во время планирования фоновых процессов автовакуума, которые сильно мешали распараллельнию работы. Вместе с 10.4 вышли обновления 9.6.9, 9.5.13, 9.4.18, 9.3.23.

Feature freeze

Это, конечно, главное событие для сообщества. То, что не прошло только что закончившийся комитфест, не попадет в версию PostgreSQL 11.

Что заморозили на feature freeze
Это наша сводка попавших в нее важнейших патчей.
Сводка сводкой, а статьи об PostgreSQL 11 уже начали появляться. А дальше — больше.

Waiting for PostgreSQL 11 – Transforms for jsonb to PL/Python and to PL/Perl
Депеш, то есть Хуберт 'depesz' Любашевски, пишет в своем блоге о 2 соответствующих патчах Антона Быкова из Postgres Professional.

Postgres 11 highlight — Covering Indexes
В своем блоге Мишель Пакье (Michael Paquier) пишет о покрывающих индексах (см также статью Что нового в PostgreSQL 11: INCLUDE-индексы Александра Алексеева из Postgres Professional и комментарии к ней). На эту же тему — INCLUDE-индексов — статья Waiting for PostgreSQL 11: Covering + unique indexes Алексея Лесковского из Data Egret.

Partition Elimination in PostgreSQL 11
По поводу этого серьезного достижения 11-й версии пишет в своей статье Дэвид Роули (David Rowley) из 2ndQuadrant.

Об еще одном патче, прошедшем в PostgreSQL 11, пишет в статье Что нового в PostgreSQL 11: встроенный веб-поиск тот же Александр Алексеев.

Manipulating checksums of a cluster
Мишель Пакье пишет еще об одном патче PostgreSQL 11. Патч проверяет чексуммы страниц после штатной остановки кластера. Более того, он предлагает свою утилиту pg_checksums на базе этого патча.

8-го апреля закончился комитфест 2018-03. Те патчи, которые не закомичены на нем (и на 3 предыдущих комитфестах) уже не попадут в релиз PostgreSQL 11: произошла заморозка функциональности (feature freeze). Время подводить итоги.

Главные новости последнего комитфеста (и версии 11 соответственно):

• увесистый набор патчей для секционирования.
• JIT-компиляции посвящен только один патч, но это шаг в направлении, которое в будущем наверняка будет развиваться интенсивно.
• «покрывающие» индексы (INCLUDE-индексы). Это тема уже активно обсуждается и продолжается в разработках.
• Серия патчей в группе процедурных языков. Они важны в том числе для совместимости со стандартами SQL и миграции с Oracle.
• Интересные, но не столь резонансные патчи.

Начнем в произвольном порядке.

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

В версии 10 перешли к более специализированным механизмам и более привычному (в том числе для пользователей Oracle, а с этим приходится считаться) синтаксису. Этот скачок при переходе от 10 к версии 11 должен был подкрепиться важными дополнениями, которые должны расширить функциональность и улучшить производительность операций, использующих секционирование. Но из итогов последнего комитфеста (он закончился 8 апреля) видно, что не все задуманное удалось довести до рабочего состояния, а значит не все попадет в версию 11.

К тому же последние пару лет параллельно велись разработки модуля pg_pathman в Postgres Professional. Некоторые важные возможности пересеклись, некоторые остались уникальны для PostgreSQL и pg_pathman (который работает с ванильной версией, то есть PostgreSQL 10 + pg_pathman дает уже вполне впечатляющую сумму функциональности). Об этом будет отдельная статья. Замечания, относящиеся к версии 11 и к pg_pathman для удобства выделены курсивом.

Эта статья представляет собой переработанные и дополненные фрагменты книжки Nouveaulités de PostgreSQL 10. (с) Dalibo, перевод с французского Игоря Лёвшина (оригинал). Примеры из книги проверены, иногда адаптированы и локализованы для большей наглядности.

(В статье использованы примеры и пояснения из книги Nouveaulités de PostgreSQL 10. (с) Dalibo, перевод с французского Игоря Лёвшина, редактор Егор Рогов (оригинал). Примеры проверены, иногда изменены для большей наглядности)

Конечно, мы уже ждем не дождемся появления 11-й версии PostgreSQL. Но уже сейчас ясно, что некоторые довольно радикальные улучшения производительности появились уже в версии 10. Определенно есть смысл разобраться сначала с ними.

Производительность "десятки" улучшилась сразу в нескольких направлениях. В этой статье речь пойдет об ускорении за счет:

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

Мы начнем с параллелизма.