Введение

Начиная с PostgreSQL 10, сообщество каждый год выпускает основную ревизию, демонстрируя свою удивительную жизнеспособность и креативность.

21 мая 2020 года Глобальная группа разработчиков PostgreSQL объявила, что первая бета-версия PostgreSQL 13 доступна для загрузки. Этот выпуск содержит предварительные версии всех функций, которые будут доступны в финальном выпуске PostgreSQL 13, хотя некоторые детали выпуска могут измениться до этого. Давайте посмотрим на новые функции и изменения, обнаруженные в PostgreSQL 13.

Новые возможности PostgreSQL 13

В опубликованном сообществом документе мы видим, что новые возможности PostgreSQL 13 разделены на следующие разделы:

• Функциональность
• Администрация
• Безопасность
• Другие основные моменты

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

Функциональность

В PostgreSQL 13 появилось много новых функций, которые помогают повысить общую производительность PostgreSQL и упростить разработку приложений.

Дедупликация индексов B-дерева

Если столбцы таблицы не уникальны, может существовать много идентичных значений. Соответствующие индексы B-дерева также могут иметь много повторяющихся записей индекса. В PostgreSQL 13 индексы B-дерева относятся к индексам GIN, чтобы связать ctid строк, на которые указывают одни и те же ключевые точки. Это усовершенствование не только уменьшает размер индекса, но также уменьшает количество ненужных разделений и увеличивает скорость поиска. Это усовершенствование называется дедупликацией индексов B-дерева. Кроме того, функция выполняется асинхронно. Эта операция выполняется только тогда, когда нужно разбить индекс B-дерева. Это снижает накладные расходы на эту функцию.

В следующем разделе описывается, как использовать дедупликацию для индексов B-дерева:

Как видите, вы должны установить для параметра хранения deduplicate_items значение «on» при создании индекса B-дерева, чтобы включить дедупликацию. В PostgreSQL 13 этот параметр хранения включен по умолчанию.

Чтобы проверить эффект этой функции, мы сравнили PostgreSQL 12 и PostgreSQL 13.

PostgreSQL 12:

PostgreSQL 13:

Основываясь на изображениях выше, мы можем увидеть следующие аспекты:

• В PostgreSQL 13 размер индекса B-дерева, который имеет тот же тип данных, что и индекс B-дерева в PostgreSQL 12, и не имеет повторяющихся значений, такой же, как и в PostgreSQL 12.
• В PostgreSQL 13 размер индекса B-дерева, который имеет тот же тип данных, что и индекс B-дерева в PostgreSQL 12, и имеет много повторяющихся значений, меньше, чем в PostgreSQL 12.
• По сравнению с PostgreSQL 12, PostgreSQL 13 требует чтения меньшего количества страниц индекса и более эффективен, если индекс имеет большое количество повторяющихся значений, а план выполнения использует сканирование только индекса.

Помимо дублирования на уровне данных, дедупликация для индексов B-дерева в PostgreSQL 13 также эффективна для работы с различными снимками повторяющихся ключей в индексе B-дерева из-за реализации MVCC. Однако дедупликацию нельзя использовать в следующих случаях:

• text, varchar и char не могут использовать дедупликацию, если используется недетерминированное сопоставление. Различия в регистре и ударении должны сохраняться среди одинаковых данных.
• numeric не может использовать дедупликацию. Масштаб числового дисплея должен сохраняться среди одинаковых базовых точек.
• jsonb не может использовать дедупликацию, потому что класс операторов jsonb B-Tree использует числовые значения внутри.
• float4 и float8 не могут использовать дедупликацию. Эти типы имеют разные представления для -0 и 0, которые, тем не менее, считаются равными. Это различие необходимо сохранить.

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

Индексы B-tree — это тип индекса по умолчанию в PostgreSQL. В сообществе несколько основных версий PostgreSQL постоянно оптимизируют занимаемое пространство и эффективность выполнения. Определенная степень дедупликации была реализована для индексов B-дерева в PostgreSQL 12.

Инкрементальная сортировка

PostgreSQL 13 добавляет инкрементную сортировку. Это улучшение происходит от собственного алгоритма. Когда группа наборов данных (X, Y) сортируется как столбцы X и Y, если текущий набор данных был отсортирован по столбцу X, конкретная сортировка показана на следующем рисунке:

(1, 5)
(1, 2)
(2, 9)
(2, 1)
(2, 5)
(3, 3)
(3, 7)

На данный момент вам нужно только сгруппировать наборы данных по столбцу X и отсортировать столбцы Y в каждой группе, чтобы получить набор результатов на основе сортировки по столбцам X и Y, как показано на следующем рисунке:

(1, 5) (1, 2)

(2, 9) (2, 1) (2, 5)

(3, 3) (3, 7)

=============== ======

(1, 2)

(1, 5)

(2, 1)

(2, 5)

(2, 9)

(3, 3)

(3, 7)

Преимущества этого алгоритма очевидны, особенно для больших наборов данных, поскольку он позволяет каждый раз уменьшать объем сортируемых данных. Вы можете использовать определенный элемент управления политикой, чтобы каждый раз объем данных при сортировке лучше соответствовал текущему work_mem. Более того, в исполнителе водопадных моделей PostgreSQL мы можем получить некоторые наборы результатов без сортировки всех данных, что очень подходит для запросов Top-N с ключевым словом Limit.

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

1. Выборка относительно безопасного количества строк не требует проверки предыдущих ключей сортировки для полной сортировки. Безопасность здесь основана на некоторых соображениях стоимости.
2. Все строки выбираются, группируются и сортируются на основе предыдущих ключей сортировки.

В PostgreSQL оптимизатор предпочитает шаблон 1 и эвристически использует шаблон 2.

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

postgres=# create table t (a int, b int, c int);
CREATE TABLE
postgres=# insert into t select mod(i,10),mod(i,10),i from generate_series(1,10000) s(i);
INSERT 0 10000
postgres=# create index on t (a);
CREATE INDEX
postgres=# analyze t;
ANALYZE
postgres=# set enable_incrementalsort = off;
SET
postgres=# explain analyze select a,b,sum(c) from t group by 1,2 order by 1,2,3 limit 1;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
Limit (cost=231.50..231.50 rows=1 width=16) (actual time=2.814..2.815 rows=1 loops=1)
-> Sort (cost=231.50..231.75 rows=100 width=16) (actual time=2.813..2.813 rows=1 loops=1)
Sort Key: a, b, (sum(c))
Sort Method: top-N heapsort Memory: 25kB
-> HashAggregate (cost=230.00..231.00 rows=100 width=16) (actual time=2.801..2.804 rows=10 loops=1)
Group Key: a, b
Peak Memory Usage: 37 kB
-> Seq Scan on t (cost=0.00..155.00 rows=10000 width=12) (actual time=0.012..0.951 rows=10000 loops=1)
Planning Time: 0.169 ms
Execution Time: 2.858 ms
(10 rows)postgres=# set enable_incrementalsort = on;
SET
postgres=# explain analyze select a,b,sum(c) from t group by 1,2 order by 1,2,3 limit 1;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=133.63..146.52 rows=1 width=16) (actual time=1.177..1.177 rows=1 loops=1)
-> Incremental Sort (cost=133.63..1422.16 rows=100 width=16) (actual time=1.176..1.176 rows=1 loops=1)
Sort Key: a, b, (sum(c))
Presorted Key: a, b
Full-sort Groups: 1 Sort Method: quicksort Average Memory: 25kB Peak Memory: 25kB
-> GroupAggregate (cost=120.65..1417.66 rows=100 width=16) (actual time=0.746..1.158 rows=2 loops=1)
Group Key: a, b
-> Incremental Sort (cost=120.65..1341.66 rows=10000 width=12) (actual time=0.329..0.944 rows=2001 loops=1)
Sort Key: a, b
Presorted Key: a
Full-sort Groups: 3 Sort Method: quicksort Average Memory: 28kB Peak Memory: 28kB
Pre-sorted Groups: 3 Sort Method: quicksort Average Memory: 71kB Peak Memory: 71kB
-> Index Scan using t_a_idx on t (cost=0.29..412.65 rows=10000 width=12) (actual time=0.011..0.504 rows=3001 loops=1)
Planning Time: 0.164 ms
Execution Time: 1.205 ms
(15 rows)

Расширенное разбиение

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

Другие

• Запросы с предложениями OR или списками констант IN / ANY могут использовать расширенную статистику (созданную с помощью CREATE STATISTICS), что может привести к лучшему планированию и повышению производительности.
• PostgreSQL 13 позволяет агрегированию хэшей использовать дисковое хранилище (enable_hashagg_disk = on) для больших наборов результатов агрегирования. Раньше избегали агрегирования хэшей, если предполагалось использовать больше, чем память work_mem.
• Также добавлена ​​функция .datetime () для запросов jsonpath, которая автоматически преобразует строку типа даты или времени в соответствующий тип данных даты или времени PostgreSQL.
• Также теперь стало проще генерировать случайные UUID, потому что функцию gen_random_uuid () можно использовать без включения каких-либо расширений.

Администрация

Параллельный ВАКУУМ

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

• В настоящее время эта функция применима только к индексам. Каждому индексу может быть назначен вакуумный работник.
• Для ПОЛНОГО VACUUM параллельная обработка не поддерживается.
• Вариант параллельности действителен только для таблиц с минимум двумя индексами.

Мы сравнили PostgreSQL 13 и PostgreSQL 12 с точки зрения VACUUM. Результаты представлены ниже:

=================================PG 13 parallel vacuum===============================
postgres=# create table testva(id int,info text);
CREATE TABLE
Time: 2.334 ms
postgres=# insert into testva select generate_series(1,1000000),md5(random()::text);
INSERT 0 1000000
Time: 1448.098 ms (00:01.448)
postgres=# create index idx_testva on testva(id);
CREATE INDEX
Time: 364.988 ms
postgres=# create index idx_testva_info on testva(info);
CREATE INDEX
Time: 873.416 ms
postgres=# vacuum (parallel 4) testva;
VACUUM
Time: 114.846 ms
=================================PG 12 normal vacuum===============================
postgres=# create table testva(id int,info text);
CREATE TABLE
Time: 5.817 ms
postgres=# insert into testva select generate_series(1,1000000),md5(random()::text);
INSERT 0 1000000
Time: 3023.958 ms (00:03.024)
postgres=# create index idx_testva on testva(id);
CREATE INDEX
Time: 631.632 ms
postgres=# create index idx_testva_info on testva(info);
CREATE INDEX
Time: 1374.849 ms (00:01.375)
postgres=# vacuum testva;
VACUUM
Time: 216.944 ms

Согласно этому сравнению, скорость VACUUM PostgreSQL 13 намного выше, чем PostgreSQL 12. Тем не менее, есть еще возможности для улучшения параллельной VACUUM. Хорошая новость заключается в том, что сообщество активно обсуждает параллельный VACUUM на уровне блоков в электронных письмах. Для получения дополнительной информации перейдите по ссылке.

Другие

• Команда reindexdb также добавила параллелизм с помощью флага new — jobs, который позволяет указать количество одновременных сеансов, которые будут использоваться при переиндексации базы данных.
• PostgreSQL 13 вводит понятие «доверенного расширения», которое позволяет суперпользователю указывать расширения, которые пользователь может установить в своей базе данных, если у него есть привилегия CREATE.
• Этот выпуск включает больше способов отслеживания действий в базе данных PostgreSQL. PostgreSQL 13 теперь может отслеживать статистику использования WAL, выполнение потокового резервного копирования и выполнение команды ANALYZE.
• pg_basebackup также может генерировать манифест, который можно использовать для проверки целостности резервной копии с помощью нового инструмента под названием pg_verifybackup.
• Также теперь можно ограничить объем пространства WAL, зарезервированного слотами репликации, и создать
• временные слоты потоковой репликации для резервных экземпляров PostgreSQL.
• Новый флаг для pg_dump, — include-foreign-data, включает данные с серверов, на которые ссылаются оболочки сторонних данных в выводе дампа.
• Команда pg_rewind также имеет улучшения в PostgreSQL 13. Помимо запуска этой команды для автоматического восстановления после сбоя, теперь вы можете использовать ее для настройки резервных экземпляров PostgreSQL с помощью флага — write-recovery-conf. pg_rewind также может использовать команду restore_command целевого экземпляра для получения необходимых журналов упреждающей записи.

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

Безопасность

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

• libpq, библиотека соединений, которая поддерживает psql и многие драйверы соединений PostgreSQL, включает несколько новых параметров, помогающих защитить соединения. PostgreSQL 13 вводит параметры соединения channel_binding, которые позволяют клиенту указать, что он хочет, чтобы функция привязки канала требовалась как часть SCRAM. Кроме того, клиент, использующий защищенный паролем сертификат TLS, теперь может указать свой пароль с помощью параметра sslpassword. PostgreSQL 13 также добавляет поддержку сертификатов в кодировке DER.
• Оболочка посторонних данных PostgreSQL (postgres_fdw) также получила несколько улучшений в плане защиты соединений, включая возможность использования аутентификации на основе сертификатов для подключения к другим кластерам PostgreSQL. Кроме того, непривилегированные учетные записи теперь могут подключаться к другой базе данных PostgreSQL через postgres_fdw без использования пароля.

Другие основные моменты

• PostgreSQL 13 продолжает улучшать работоспособность в Windows. Пользователи, использующие PostgreSQL в Windows, теперь имеют возможность подключаться через сокеты домена UNIX.
• В документации PostgreSQL 13 добавлен глоссарий терминов, чтобы помочь людям ознакомиться как с PostgreSQL, так и с общими концепциями баз данных. Это совпадает со значительной переработкой отображения функций и операторов в таблицах, что помогает улучшить читаемость как в Интернете, так и в документации PDF.
• Утилита pgbench, используемая для тестирования производительности, теперь поддерживает возможность разделения своей таблицы «учетных записей», что упрощает тестирование рабочих нагрузок, содержащих разделы.
• Инструмент psql теперь включает команду warn, аналогичную команде echo с точки зрения вывода данных, за исключением того, что warn отправляет ее в stderr. Если вам нужны дополнительные инструкции по командам PostgreSQL, флаг — help теперь включает ссылку на https://www.postgresql.org .

Для получения дополнительной информации о других функциях PostgreSQL 13 перейдите по ссылке.

Резюме

Хотя в PostgreSQL 13 не были представлены запланированные функции TDE и zheap, в нем все еще есть много привлекательных функций, включая дедупликацию для индексов B-дерева, параллельное VACUUM и использование диска с помощью агрегации хэшей. Более того, вы можете использовать новый инструмент pg_verifybackup для проверки целостности резервной копии и использовать pg_rewind для настройки резервных экземпляров PostgreSQL. pg_rewind также может использовать команду restore_command целевого экземпляра для получения необходимых журналов упреждающей записи. Если вам интересно, вы можете скачать исходный код, скомпилировать его, проанализировать реализацию интересующих вас функций. Возможно, вы получите лучшие идеи.