Feature freeze что это
Что заморозили на feature freeze
8-го апреля закончился комитфест 2018-03. Те патчи, которые не закомичены на нем (и на 3 предыдущих комитфестах) уже не попадут в релиз PostgreSQL 11: произошла заморозка функциональности (feature freeze). Время подводить итоги.
JIT-компиляция
JIT compiling expressions & tuple deforming
Без JIT выполнение запроса представляет собой интерпретацию плана выполнения. С JIT, то есть с компиляцией just-in-time, или «на лету», отдельные части запроса компилируются, и за счет этого запрос выполняется быстрее. Характерный пример — JIT-компиляция выражений в SQL-запросах. В этом патче, автор которого Андрес Фройнд из EnterpriseDB, есть и психологическая составляющая: для JIT теперь задействован компилятор LLVM — его называют даже «компиляторной инфраструктурой». Он часто используется именно для JIT, он удобен, позволяет встраивать функции в код (inline), оптимизирует код и он достаточно универсален с точки зрения целевых платформ. При деформинге записей (разворачивании строк в памяти) тоже используется LLVM, и это тоже повышает производительность.
INCLUDE-индексы
Covering B-tree indexes (aka INCLUDE)
INCLUDE-индексы — большой патч российского просхождения, его начала разратывать еще 2 года назад Анастасия Лубенникова и продолжили Александр Коротков и Федор Сигаев (все они из Postgres Professional — ну да, мы неравнодушны к отечественному вкладу в комьюнити). INCLUDE-индексы иногда называют покрывающими индексами, но, строго говоря, покрывающим индексом для конкретного запроса называется индекс, который содержит все необходимые в запросе столбцы таблицы. А смысл INCLUDE-индексов в том, чтобы индекс мог стать покрывающим не за счет включения в него дополнительных столбцов, а за счет хранения дополнительной информации (неиндексированных значений). Например, таким образом можно расширить уникальный индекс, который останется при этом уникальным.Они позволяют увеличить производительность, так как index only scan обычно намного быстрее, а по сравнению с другими способами перейти к index only scan они менее громоздки: можно обойтись одним индексом там, где нужно было 2 и больше, а значит меньше времени и ресурсов тратится на обновление индексов при вставке и обновлении. Патч Covering B-tree indexes (aka INCLUDE) — это тоже первый шаг потому, что дальше последует поддержка покрывающих индексов для других их видов: уже начата, например, работа по поддержке GiST.
Примеры есть в блоге Александра Алексеева (Postgres Pro) и блоге Алексея Лесовского (Data Egret).
Новое в процедурных языках (по Айзентрауту)
SQL procedures,
Transaction control in procedures,
PL/pgSQL nested CALL with transactions,
SET TRANSACTION in PL/pgSQL,
INOUT parameters in procedures
Эти патчи авторства Питера Айзентраута из 2ndQuadrant делают процедурные языки PostgreSQL процедурными в буквальном смысле: кроме хранимых функций теперь будут и полноценные хранимые процедуры. Патч SQL procedures принят в конце прошлого года. С тех пор интерпретатору стал понятен синтаксис с командами CREATE/ALTER/DROP PROCEDURE, вызов процедуры CALL, а также ROUTINE. В январе добавлено самое ценное — управление транзакциями в процедурах: Transaction control in procedures. А вот этот патч INOUT позволяет создавать процедуры таким образом:Раньше SET TRANSACTION возможно было только в SQL, но не в plpgsql. С патчем это уже возможно, и это тоже шаг навстречу мигрирующим с Oracle. Также возможны теперь и вложенные вызовы функций (и DO) с транзакциями.
Секционирование
Над этой большой серией патчей работала команда NTT — Амит Лангот (Amit Langote), разработчики из 2ndQuadrant и другие. Еще в ноябре прошлого года был принят патч, добавляющий секционирование по хешу. Теперь все основные виды секционирования в PostgreSQL есть.
Но самая важная новость другая: серия патчей дает возможность создавать уникальные индексы, PRIMARY KEY глобально на всей секционированной таблице (об этом можно найти некоторую информацию например здесь: unique indexes on partitioned tables. Следовательно можно создавать и таблицы, ссылающиеся на секционированную таблицу: foreign keys and partitioned tables. Можно будет обновлять секционированную таблицу, не думая о том, останется ли запись в той же секции (версия 10 выдала бы ошибку): UPDATE of partition key. Появился ON CONFLICT DO UPDATE for partitioned tables.
То есть обращаться с секционированной таблицей можно почти как с обычной. Почти — потому, что возможности будут работать только если в уникальный индекс входят поля, составляющие ключ разбиения (partition key). Но это огромный шаг в любом случае.
Что касается Add support for tuple routing to foreign partitions, то этот патч, который автоматически направляет вставляемые записи во внешние секции, важен в том числе для тех, кто будет создавать системы с шардингом на базе новых возможностей секционирования.
Важнейшее умение оптимизатора — эффективно исключать из плана секции, в которых заведомо нет данных (патч faster partition pruning in planner). В случае, когда секций много (а в реальных проектах встречаются тысячи, а то и десятки тысяч), исключение секций (pruning) может серьезно снизить время исполнения запроса. Исключать нежелательных можно будет и на этапе исполнения (патч Runtime Partition Pruning), когда заранее не известно условие попадания в ту или иную секцию. Так случается, например, в запросах с подзапросами.
Partition-wise join for declarative partitioned tables представляет собой реализацию алгоритмов соединения двух секционированных таблиц. Соединение происходит отдельно по секциям, а потом собирается вместе. Во многих случаях это быстрее, чем соединять родительские таблицы. Аналогично при Partition-wise aggregation/grouping агрегирование охватывает сначала отдельные секции, потом результаты собирают.
Среди удобств появится секция по умолчанию (Default Partition for Range), куда попадали бы все записи, выходящие за границы заданных секций, чтобы не останавливаться каждый раз из-за ошибки. Автоматическое создание секций под данные, диапазон которых заранее не известен, пока даже не планируется (это умеет делать расширение pg_pathman).
JSON(B)
В этом направлении усилия делаются уже более 2 лет командой разработчиков Postgres Pro. Поскольку патчи увесистые и затрагивают многие механизмы postgres, принимаются сообществом они неторопливо. В PostgreSQL 11 вошли 3 патча:
Jsonb transform for pl/perl и
Jsonb transform for pl/python Антона Быкова (эффективные трансформации бинарных JSON при передаче их в функции Perl и Python) и
Cast jsonb to numeric, int, float, bool Анастасии Лубенниковой (преобразование типов). Но такие ключевые патчи как
SQL/JSON support in PostgreSQL, или
SQL/JSON: jsonpath, или
SQL/JSON: functions
по-прежнему ждут. А ведь это поддержка стандарта SQL/JSON.
В контексте JSON можно упомянуть и патч Константина Книжника, полезные для сюръективных (surjective) функций работающих с JSON, например вида (info->>’name’). но может пригодиться и для других целей.
Параллельные Gather и сортировка при создании индексов B-tree
Gather speed-up более рационально работает с очередями в памяти, ускоряет запросы, особенно простые.
Parallel tuplesort (for parallel B-Tree index creation). Это еще январский патч — параллельная сортировка записей для индексов B-tree.
VACUUM
Не слишком принципиальное изменение, но все же: теперь можно запускать VACUUM нескольких таблиц одной командой: Allow users to specify multiple tables in VACUUM commands. Патч принят еще в конце прошлого года. В то же время важнейшие патчи, касающиеся приоритетов вакуумизации различных таблиц, расписания вакуумирования пока ждут.
Логическая репликация
Она в ванильной PostgreSQL продвинулась не сильно. Появилась поддержка TRUNCATE: Logical decoding of TRUNCATE
Контрольные суммы
Verify Checksums during Basebackups. Теперь можно проверять контрольные суммы в процессе бэкапа (если контрольные суммы включены).
Вклад в версию 11 отечественных разработчиков существенный. Но это тема другого рассказа. А пока — спасибо всем разработчикам (и ревьюерам) грядущего релиза!
[фото автора. на фото заfreezeн герой фильма «Левиафан» — г.Кировск, Кольский п-ов.]
С++23 — feature freeze близко
Прошло четыре месяца с прошлой онлайн-встречи ISO-комитета, а значит, настало время собраться опять.
В этот раз в черновик нового стандарта C++23 добавили весьма полезные и вкусные новинки:
Многомерный operator[]
При разработке класса многомерного спана std::mdspan комитет столкнулся с проблемой многомерного индексирования. На примере массива с пятью измерениями:
Чтобы не делать таких безобразий (и по просьбам разработчиков математических библиотек) в C++ был добавлен многомерный operator[] (P2128). Его можно перегружать для любых типов, что позволяет делать принципиально новые интерфейсы:
Монадические интерфейсы для std::optional
Если вы не знаете, что такое «монады» — не расстраивайтесь, я тоже не знаю. Это знание не нужно, чтобы пользоваться новыми интерфейсами std::optional (P0798):
std::move_only_function
И тут заметили проблему: type-erased-контейнеры std::function и std::any требуют копируемости хранимого типа. Иначе получаем ошибку компиляции.
Фикс подоспел к С++23, приняли std::move_only_function (P0288), который не требует конструкторов копирования и перемещения. Теперь, если ваш алгоритм не требует, чтобы функтор копировался, просто принимайте на вход новый тип данных:
basic_string::resize_and_overwrite
Для любителей сильнее оптимизировать код в C++23 добавили возможность увеличить размер строки и сразу проинициализировать новые символы (P1072):
Результат будет аналогичен следующему коду:
Больше гетерогенных методов
График, показывающий прирост производительности при использовании новых методов, как раз вынесен в шапку этого поста. Больше графиков и детали можно найти в самом предложении: P2077. Большое спасибо нашим ребятам из Intel за отлично проделанную работу!
zip, zip_transform, adjacent, adjacent_transform
Ranges обзавелись новыми view для «склеивания» элементов диапазона (P2321):
Не стоит забывать, что ranges — ленивые:
Транзакционная память
Комитет уже делал подход к транзакционной памяти Transactional TS, и этот подход показал себя совершенно несостоятельным: в стандарт вносилось слишком много правок, приходилось переделывать стандартную библиотеку, порой дублируя функции.
Поэтому решили сделать новый подход! Простой и элегантный:
Новый подход всё ещё экспериментальный, в ближайшее время он будет выпущен в виде TS, основанного на P2066.
На мой взгляд, у подхода есть несколько больших недостатков:
Получение std::stacktrace из исключения
От РГ21 есть замечательное предложение Stacktrace from exception, которое позволяет получить стектрейс из любого исключения без модификации кода, который выкидывает это исключение:
Такой пример может вывести следующее:
Caught exception: map::at, trace:
0# get_data_from_config(std::string_view) at /home/axolm/basic.cpp:600
1# bar(std::string_view) at /home/axolm/basic.cpp:6
2# main at /home/axolm/basic.cpp:17
Если честно, я не верил, что комитет успеет принять эту идею в C++23. Но внезапно предложение понравилось многим комитетским старожилам, и появился шанс успеть втащить его в стандарт на одном из заседаний 2021 года, которые будут последними перед feature freeze.
Итоги и feature freeze
Кстати, 15-18 ноября состоится конференция C++ Russia, где можно будет узнать новости о развитии C++ и пообщаться с многими представителями комитета.
Что заморозили на feature freeze
8-го апреля закончился комитфест 2018-03. Те патчи, которые не закомичены на нем (и на 3 предыдущих комитфестах) уже не попадут в релиз PostgreSQL 11: произошла заморозка функциональности (feature freeze). Время подводить итоги.
JIT-компиляция
JIT compiling expressions & tuple deforming
Без JIT выполнение запроса представляет собой интерпретацию плана выполнения. С JIT, то есть с компиляцией just-in-time, или «на лету», отдельные части запроса компилируются, и за счет этого запрос выполняется быстрее. Характерный пример — JIT-компиляция выражений в SQL-запросах. В этом патче, автор которого Андрес Фройнд из EnterpriseDB, есть и психологическая составляющая: для JIT теперь задействован компилятор LLVM — его называют даже «компиляторной инфраструктурой». Он часто используется именно для JIT, он удобен, позволяет встраивать функции в код (inline), оптимизирует код и он достаточно универсален с точки зрения целевых платформ. При деформинге записей (разворачивании строк в памяти) тоже используется LLVM, и это тоже повышает производительность.
INCLUDE-индексы
Covering B-tree indexes (aka INCLUDE)
INCLUDE-индексы — большой патч российского просхождения, его начала разратывать еще 2 года назад Анастасия Лубенникова и продолжили Александр Коротков и Федор Сигаев (все они из Postgres Professional — ну да, мы неравнодушны к отечественному вкладу в комьюнити). INCLUDE-индексы иногда называют покрывающими индексами, но, строго говоря, покрывающим индексом для конкретного запроса называется индекс, который содержит все необходимые в запросе столбцы таблицы. А смысл INCLUDE-индексов в том, чтобы индекс мог стать покрывающим не за счет включения в него дополнительных столбцов, а за счет хранения дополнительной информации (неиндексированных значений). Например, таким образом можно расширить уникальный индекс, который останется при этом уникальным.Они позволяют увеличить производительность, так как index only scan обычно намного быстрее, а по сравнению с другими способами перейти к index only scan они менее громоздки: можно обойтись одним индексом там, где нужно было 2 и больше, а значит меньше времени и ресурсов тратится на обновление индексов при вставке и обновлении. Патч Covering B-tree indexes (aka INCLUDE) — это тоже первый шаг потому, что дальше последует поддержка покрывающих индексов для других их видов: уже начата, например, работа по поддержке GiST.
Примеры есть в блоге Александра Алексеева (Postgres Pro) и блоге Алексея Лесовского (Data Egret).
Новое в процедурных языках (по Айзентрауту)
SQL procedures,
Transaction control in procedures,
PL/pgSQL nested CALL with transactions,
SET TRANSACTION in PL/pgSQL,
INOUT parameters in procedures
Эти патчи авторства Питера Айзентраута из 2ndQuadrant делают процедурные языки PostgreSQL процедурными в буквальном смысле: кроме хранимых функций теперь будут и полноценные хранимые процедуры. Патч SQL procedures принят в конце прошлого года. С тех пор интерпретатору стал понятен синтаксис с командами CREATE/ALTER/DROP PROCEDURE, вызов процедуры CALL, а также ROUTINE. В январе добавлено самое ценное — управление транзакциями в процедурах: Transaction control in procedures. А вот этот патч INOUT позволяет создавать процедуры таким образом:Раньше SET TRANSACTION возможно было только в SQL, но не в plpgsql. С патчем это уже возможно, и это тоже шаг навстречу мигрирующим с Oracle. Также возможны теперь и вложенные вызовы функций (и DO) с транзакциями.
Секционирование
Над этой большой серией патчей работала команда NTT — Амит Лангот (Amit Langote), разработчики из 2ndQuadrant и другие. Еще в ноябре прошлого года был принят патч, добавляющий секционирование по хешу. Теперь все основные виды секционирования в PostgreSQL есть.
Но самая важная новость другая: серия патчей дает возможность создавать уникальные индексы, PRIMARY KEY глобально на всей секционированной таблице (об этом можно найти некоторую информацию например здесь: unique indexes on partitioned tables. Следовательно можно создавать и таблицы, ссылающиеся на секционированную таблицу: foreign keys and partitioned tables. Можно будет обновлять секционированную таблицу, не думая о том, останется ли запись в той же секции (версия 10 выдала бы ошибку): UPDATE of partition key. Появился ON CONFLICT DO UPDATE for partitioned tables.
То есть обращаться с секционированной таблицей можно почти как с обычной. Почти — потому, что возможности будут работать только если в уникальный индекс входят поля, составляющие ключ разбиения (partition key). Но это огромный шаг в любом случае.
Что касается Add support for tuple routing to foreign partitions, то этот патч, который автоматически направляет вставляемые записи во внешние секции, важен в том числе для тех, кто будет создавать системы с шардингом на базе новых возможностей секционирования.
Важнейшее умение оптимизатора — эффективно исключать из плана секции, в которых заведомо нет данных (патч faster partition pruning in planner). В случае, когда секций много (а в реальных проектах встречаются тысячи, а то и десятки тысяч), исключение секций (pruning) может серьезно снизить время исполнения запроса. Исключать нежелательных можно будет и на этапе исполнения (патч Runtime Partition Pruning), когда заранее не известно условие попадания в ту или иную секцию. Так случается, например, в запросах с подзапросами.
Partition-wise join for declarative partitioned tables представляет собой реализацию алгоритмов соединения двух секционированных таблиц. Соединение происходит отдельно по секциям, а потом собирается вместе. Во многих случаях это быстрее, чем соединять родительские таблицы. Аналогично при Partition-wise aggregation/grouping агрегирование охватывает сначала отдельные секции, потом результаты собирают.
Среди удобств появится секция по умолчанию (Default Partition for Range), куда попадали бы все записи, выходящие за границы заданных секций, чтобы не останавливаться каждый раз из-за ошибки. Автоматическое создание секций под данные, диапазон которых заранее не известен, пока даже не планируется (это умеет делать расширение pg_pathman).
JSON(B)
В этом направлении усилия делаются уже более 2 лет командой разработчиков Postgres Pro. Поскольку патчи увесистые и затрагивают многие механизмы postgres, принимаются сообществом они неторопливо. В PostgreSQL 11 вошли 3 патча:
Jsonb transform for pl/perl и
Jsonb transform for pl/python Антона Быкова (эффективные трансформации бинарных JSON при передаче их в функции Perl и Python) и
Cast jsonb to numeric, int, float, bool Анастасии Лубенниковой (преобразование типов). Но такие ключевые патчи как
SQL/JSON support in PostgreSQL, или
SQL/JSON: jsonpath, или
SQL/JSON: functions
по-прежнему ждут. А ведь это поддержка стандарта SQL/JSON.
В контексте JSON можно упомянуть и патч Константина Книжника, полезные для сюръективных (surjective) функций работающих с JSON, например вида (info->>’name’). но может пригодиться и для других целей.
Параллельные Gather и сортировка при создании индексов B-tree
Gather speed-up более рационально работает с очередями в памяти, ускоряет запросы, особенно простые.
Parallel tuplesort (for parallel B-Tree index creation). Это еще январский патч — параллельная сортировка записей для индексов B-tree.
VACUUM
Не слишком принципиальное изменение, но все же: теперь можно запускать VACUUM нескольких таблиц одной командой: Allow users to specify multiple tables in VACUUM commands. Патч принят еще в конце прошлого года. В то же время важнейшие патчи, касающиеся приоритетов вакуумизации различных таблиц, расписания вакуумирования пока ждут.
Логическая репликация
Она в ванильной PostgreSQL продвинулась не сильно. Появилась поддержка TRUNCATE: Logical decoding of TRUNCATE
Контрольные суммы
Verify Checksums during Basebackups. Теперь можно проверять контрольные суммы в процессе бэкапа (если контрольные суммы включены).
Вклад в версию 11 отечественных разработчиков существенный. Но это тема другого рассказа. А пока — спасибо всем разработчикам (и ревьюерам) грядущего релиза!
[фото автора. на фото заfreezeн герой фильма «Левиафан» — г.Кировск, Кольский п-ов.]
Feature freeze C++20. Coroutines, Modules и прочее
На днях прошла встреча международного комитета по стандартизации C++ в американском городе Кона. Это была не просто встреча, а feature freeze! Никакие серьёзные новые идеи больше не могут просачиваться в стандарт, остаётся лишь пара встреч на добавление предварительно одобренных вещей, исправление недочётов и устранение шероховатостей.
Ожидать ли Модули и Корутины в C++20, будет ли там быстрая библиотека для форматирования вывода, сможет ли она работать с календарями, добавили ли std::stacktrace, начнёт ли компилятор сам вызывать std::move в ряде случаев, приняли ли std::flat_map? Всё это и многое другое ожидает вас под катом.
Coroutines TS
Самые жаркие дебаты разгорелись вокруг сопрограмм. Комитету предстояло рассмотреть три различных подхода к сопрограммам и решить, принимать в стандарт имеющиеся Coroutines TS, либо идти другим путём.
Выбор был не простой, у каждого подхода есть свои минусы и плюсы:
Modules
На обсуждение модулей повлиял один интересный документ с замерами производительности:
P1441R0. Трактовать результаты можно по разному: от «существующие системы сборки и реализация модулей ещё недостаточно оптимизированы» до «модули плохо масштабируются с ростом сложности проекта».
Помимо этого документа, комитет обсудил ряд небольших правок к текущим модулям. В итоге, спустя 15 лет обсуждения, прототипирования и экспериментов с внедрениями, модули были приняты в C++20.
Format
Good news everyone! Если не найдут фатальных недостатков в подгруппе Library, то в C++20 можно будет безопасно и очень быстро форматировать строки. Скажите «до свидания» std::ios, std::locale и прочим ужасам 90-х! Теперь Python подобный синтаксис для форматирования доступен из коробки в С++: P0645R5.
Более того, было принято предложение на интеграцию нового форматирования и календарных времён P1361R0. Если всё пойдёт по плану, то и даты можно будет выводить по-человечески!
Networking, Executors и Properties
Executors являются важным кирпичиком для поддержки Networking в C++ из коробки. Для Executors нужны Properties — возможность модифицировать тип данных, в зависимости от параметра переданного на этапе компиляции, не меняя концепт типа.
Properties описаны в P1393R0. Не смотря на то, что текста для включения в стандарт всего пара страничек, предложение вызвало бурные обсуждения. Предложение позволяет делать практически всесильные точки кастомизации, менять поведение любых функций, использующих Properties.
В итоге решено было Properties включать в язык только в C++23, а соответственно и Executors, и Networking в C++20 не появятся.
Прочее
В черновик C++20 уже были внесены следующие изменения:
Заслуги РГ21
В самый первый день за горячо любимое в Яндекс.Такси предложение на Stacktrace P0881R3 взялась подгруппа Core. Замечания по дизайну были дополнительно обсуждены в подгруппе LEWG, ещё раз проработаны в Core. В итоге в течении всей недели вносились правки и велись обсуждения. В черновик стандарта предложение ещё не включено, но должно оказаться в C++20 (если не найдут вдруг какой-то фатальный недостаток).
До обсуждения нашей идеи P1485R0 на приведение ключевых слов для корутин дело не дошло.
Также в SG1 Concurrency обсуждали идею concurrent unordered map P0652R2. Нас попросили перепроверить, что предложенное API позволяет избежать reader contention. Также сказали поисследовать concurrent unordered контейнеры, которые не имеют функции erase и не защищают значение контейнера от конкурентной модификации.
Предложение от ZaMaZaN4iK на специализацию std::hash для различных классов стандартной библиотеки P1406R0 решено было сильно порезать. Комитет порекомендовал оставить специализации только для std::pair, std::tuple, std::array и std::basic_string от пользовательских аллокаторов.
В подгруппе цифр SG6 обсудили механизм для взаимодействия различных новых классов чисел P0880R2. Предложение позволяет специализировать два шаблона, получить полный набор математических операций и сравнений для всех новых типов. По итогам обсуждения решили попробовать расширить механизм, чтобы им можно было пользоваться не только для нужд стандартной библиотеки, но и пользователи могли использовать эти операторы для своих типов.
Также обсуждали наши незначительные предложения, включая feature testing macro P1424R0 и политики на их добавление в стандарт.
Быстро обсудили нашу идею, позволяющую компилятору убирать лишние копирования R0889R1. Нам сказали продолжать работу в этом направлении и накидали примеров, которые не должны ломаться с новыми правилами.
Вместо итогов
C++20 будет так же разительно отличаться от C++17, как С++11 отличался от C++03. Огромное количество новых технологий и новых парадигм: Concepts, Contracts, Ranges, Modules, Coroutines, constexpr контейнеры и constexpr динамический полиморфизм, «ниблойды» и т. д.
В скором времени мы, Рабочая Группа 21, отправим комментарии к черновику стандарта C++20. Поэтому, если у вас есть какая-то боль или вы не согласны с каким-то нововведением, пожалуйста, оставляйте свои мысли на этой странице.