Вышел PostgreSQL 11



    Специальный выпуск 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 по умолчанию: этот вариант команды теперь не перезаписывает все строки таблицы и, следовательно, работает быстро.


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

    Постгресисты из HPE регулярно публикуют детальную сводку функциональности. После апрельской Feature freeze она была такова (в этом PDF есть и краткая сводка новшеств, и детали, и примеры).

    Не совсем понятны, все же, сверхбурные восторги (см. ниже реакцию Лукаса Фитла) по поводу этой версии. Сделано очень много полезного, но доделывать еще предстоит очень важные вещи, а есть направления по которым не то чтобы конь не валялся, но это лишь свет в начале тоннеля. Например, многое доделали в секционировании, спору нет, но до сих пор невозможно сослаться на секционированную таблицу при помощи FOREIGN KEY. Можно создать FOREIGN KEY, но в самой секционированной таблице. Глобальных индексов нет.

    JIT/LLVM появился, но тут же исчез из дефолтной конфигурации: по умолчанию он выключен. И это неспроста, ведь в некоторых случаях он не ускоряет, а вносит ненужные оверхеды.

    Не вошли в новую версию большие патчи с функциями для работы с JSON/JSONB.

    За подключаемыми движками хранения (pluggable storage) и, в том числе, zheap (то есть Oracle-подобный UNDO, работающий без VACUUM) многие следят с замиранием сердца. Они в эмбриональном состоянии, не утрясли еще даже API. Обзор возможностей в этом направлении есть здесь.

    Но это было лишь напоминание о том, что еще предстоит. Работа над новым и недоделанным старым идёт вовсю, направление развития понятно.

    Статьи


    New in Postgres 11: Monitoring JIT performance, Auto Prewarm & Stored Procedures
    Лукас Фитл (Lukas Fittl) не только перечисляет важнейшие новшества, но и приводит оценки производительности, листинги, планы. Лукас поясняет, что нового в расширении для предразогрева базы (pg_prewarm), напоминает об особенностях хранимых процедур, тестирует JIT. Вывод ультраоптимистический: похоже, это будет лучший релиз PostgreSQL.

    Postgres 11 — a First Look
    Крейг Кирстинс (Craig Kerstiens) обращает внимание в том числе на фичи, не расписанные выше, напоминает об изменениях в статистике, например. Или о… см. ниже.

    Adding new table columns with default values in PostgreSQL 11
    Статья о любопытном патче автора, Эндрю Данстэна (Andrew Dunstan) из 2ndQuadrant. Теперь, например, в столбце по умолчанию могут задаваться не только статические величины, но и CURRENT_TIMESTAMP или random().

    На конференциях и на вебинарах на тему PostgreSQL 11


    Питер Айзентраут (Peter Eisentraut) из 2ndQuadrant провёл вебинар по новшествам PostgreSQL 11. Запись дополнена ответами на вопросы, неотвеченные на вебинаре.

    На PGCONF.EU в Лиссабоне (вот программа) запланирован, конечно, обзорный доклад: Магнуса Хагандера (Magnus Hagander)
    What's new in PostgreSQL 11? и к нему парой
    What is old in PostgreSQL 11? Деврима Гюндюза (Devrim Gündüz).
    Towards more efficient query plans: PostgreSQL 11 and beyond Александра Кузьменкова (Postgres Professional), в котором будут упомянуты не только (и даже не столько) закоммиченные фичи, сколько то, что еще в работе.
    Также в программе есть и доклады
    PostgreSQL worst practices Ильи Космодемьянского (Data Egret)
    Do you need a Full-Text Search in PostgreSQL ? Олега Бартунова (Postgres Professional),
    Advanced PostgreSQL Backup and Recovery methods Анастасии Лубенниковой (Postgres Professional)



    Подписывайтесь на канал postgresso!

    Идеи и пожелания присылайте на почту: news_channel@postgrespro.ru
    Предыдущие выпуски: #10, #9, #8, #7, #6, #5, #4, #3, #2, #1
    Postgres Professional
    224,00
    Российский вендор PostgreSQL
    Поделиться публикацией

    Похожие публикации

    Комментарии 31

      0
      Сегодня уже обновился. Спасибо за websearch_to_tsquery!
        0
        Интересно попробовать json(b)_to_tsvector.

        Не вошли в новую версию большие патчи с функциями для работы с JSON/JSONB.
        А что там будет? Где можно почитать? К 11.1 подтянут?
          0
          А что вы там собираетесь искать? Вы что, в JSONB храните тексты?
            0
            Как это соотносится с моим вопросом?! :) Статистические данные телеметрии, хранящиеся в сложном разнородном формате. Возможно json(b)_to_tsvector() упростит запросы к JSONB, а может и нет.
              +1
              Ну просто по конкретным ключам в jsonb и сейчас можно строить индексы и искать по ним, а to_tsvector() — это функции для полнотекстового поиска (просто много работал с этим) для построения лексем из текста. Вот я и удивился немного, что за данные вы храните в таком формате, где нужно строить лексемы.
            0
            А что в этом плохого?
              –1
              Плохого? Это не то, чтобы плохо, а скорее узкое место. Если вы хотите хранить разные тексты в данном формате, то вы должны позаботится о том, что при полнотекстовом поиске у вас существуют нужные ключи с текстами. Иначе словите эксепшн. А значит вам придется делать какие-то проверки и валидаторы. А если так, то теряется основное назначение данного формата — хранение несогласованных и необязательных данных, утеря которых не приведет к падению приложения. Например, есть у вас текст «Описание к товару». Если он у вас обязателен, то его лучше хранить в отдельном текстовом поле. Сама база будет заставлять вас заполнить это поле. В случае с jsonb — это не так. И потерять в этом формате один из ключей с вашим текстом проще паренной репы на любом этапе сохранения данных в это поле.

              Выбирать формат хранения данных нужно не по модности/новаторству и т.д., а с умом, предполагая все возможные последствия данного выбора.

              Например, хранить дополнительные, но необязательные атрибуты к товару можно и нужно в jsonb. Хранить там обязательные атрибуты — это быть себе злобным буратино, так как всю ответственность с базы вы перенесете на себя и свое приложение. И при выводе на странице товара, где ожидается обязательный вывод какого-то атрибута произойдет падение сценария, так как в хранимом хэше его не окажется.

              Плюс не забываем о том, что ваше приложение может легко и не принуждено изменить структуру сохраняемых данных в jsonb, которому плевать что в себе хранить, например, после рефакторинга какого-то куска кода. А другой, старый код, пытается получить данные со старой структурой, которых там уже нет. Вот вы и поимели геморрой.
                0
                Если он у вас обязателен, то его лучше хранить в отдельном текстовом поле. Сама база будет заставлять вас заполнить это поле. В случае с jsonb — это не так.

                Лукавите. База будет заставлять в том случае, если задан constrain. Ничто не мешает завести ограничения для документа: Как использовать ограничения JSON при работе с PostgreSQL

                  0
                  Мне JSON интересен в случае, когда данные могут иметь разную структуру. Если поле одно, то это совсем не интересно и в JSON его действительно хранить смысла немного, хоть оно обязательное, хоть нет. А вот если у нас таблица с товарами, у которых есть характеристики, причём у разных типов товаров могут быть разный набор характеристик, например у процессоров это поколение, частота, размеры кешей, у жёстких дисков это размер, скорость вращения дисков и тд, да к тому же ещё и конфигурируемые пользователем но в то же время может быть желание иметь полнотекстовый поиск по определённым полям (пусть даже это будет конфигурироваться администратором БД, не суть), то хранение в JSON может быть привлекательным вариантом и полнотекстовый поиск по полям внутри этого JSON может быть нужной фичей.
                    0
                    Да, jsonb отличная штука для хранения неопределенных данных. Но вот с полнотекстовым поиском по ним у меня большой вопрос. Как и из чего конкретно будут строиться лексемы? Из всех ключей в хэше? Если это так, то мы поимеем кучу лишнего мусора при поиске. Если у нас есть конкретные текстовые поля с постоянными ключами, то можно именно на них навесить поиск, но потеряется гибкость. Кстати сейчас делать полнотекстовый поиск по ключам в jsonb тоже ничего не мешает. Удобно построить отдельную таблицу с лексемами, куда при сохранении сущности сохранять текст переводя его в to_tsvector. И уже делать поиск по этим полям. Но опять таки, теряется гибкость. В итоге мы пытаемся использовать реляционный подход к noSQL базам, что в корне неверно.

                    Я с JSONb очень много работал на огромном портале недвижимости. Очень много чего мы туда позапихивали и радовались, ровно до тех пор, пока бизнес не стал ставить задачи по агрегациям и вычислениям, с кучей пересечений по другим json полям. Запросы тогда реально превращались в десятиэтажных монстров. В итоге, часть полей пришлось переписать в отдельные таблицы со своими строгими полями. Этот формат очень крут и удобен, но нужно осторожно с ним работать, так как в будущем может понадобиться что-то сложное делать с данными и тогда работа превратится в огромную проблему.
                      +1
                      Спасибо, я тут больше теоретик, сама идея JSON мне очень нравится, т.к. обычно люди тупо сериализуют Java-объект и кладут в базу какую-то байтовую кашу-малашу или придумывают свои доморощенные разделённые запятыми форматы, конечно же обрабатывая это всё в приложении или в километрах хранимок, но на практике пока применять не приходилось, всё жду. Вот недавно почти посоветовал, но там хипсторы на Mongo решили всё делать, сдалась им эта монга.
                        +3
                        Монга штука хорошая, но опасная. Завтра бизнес скажет, а я хочу иметь всю сводную статистику по запросам к странице, по закачке данных, по кликам на баннера и т.д. И прогеры почешут репу, и начнут разбегаться кто куда.

                        Поэтому постгрес очень подходящая база для разных смешанных типов данных. Я до сих пор вижу, как народ мучается с построением деревьев с помощью кучи библиотек и костылей, хотя у постгреса есть отличный фомат ltree. Народ до сих пор строит какие-то решения из говна и палок для работы с географией, хотя у постгреса мощный функционал для работы с локациями и.т. Да, постгес после mySQL кажется громадным и сложным монстром, но для энтерпрайз проектов он решает громадное количество задач на уровне самой базы, а не кода. А монга — это что-то хипстерское, на которую был в одно время огромный спрос, который стал сходить на нет, так как многие уже наобжигались с ней. Особенно, когда работали с заказчиком по agile. Сегодня одни требования (точно, при точно), а завтра все переигралось (бизнес платит деньги, поэтому поджали яйца, делаем, что вам говорят).
              0
              Вообще по JSON/JSONB давно написаны 3 больших патча:
              SQL/JSON: jsonpath
              SQL/JSON: functions
              SQL/JSON: JSON_TABLE
              но их никак не закоммитит сообщество. О них есть вот здесь: obartunov.livejournal.com/200076.html
                +1
                Да, крутое изменение! Жаль, что уже год не могут закоммитить. Сейчас для текущего проекта очень бы пригодилось.
              0
              а если можно будет передавать секцию от одной таблицы к другой то будет вообще замечательно
                0
                ATTACH/DETACH PARTITION при ALTER TABLE появилась ещё 10-й версии
                  0
                  пропустил, спасибо
                0
                А что там нового в области бэкапа и ресторе? Можно уже делать восстановление отдельных tablespace?
                  0
                  Никаких новостей пока.
                  –4
                  Релизы PostgreSQL все унылее и унылее, зато на конференциях любят сообщать, что скоро захватят мир и круче нас никого нет. На деле получаем что-то непонятное и это видимо то, с чем хотели поиграться разработчики сообщества больше всего.
                  Очень напомнило релиз Angular 7, где сообщество опять прокатили с нужными фичами
                    0
                    Не знаю как вы, а лично я ждал секционирования по хешу с возможностью смены секции для строки во время апдейта.
                    0
                    В инсталляторе 11 версии от BigSQL лежит pgAdmin 3, который, внезапно, не работает с 11 версией.
                      0
                      Он и с 10ой какбы не работает, но работает.
                        0
                        Оригинальный, возможно, не работает. Ребята из BigSQL же делают свою LTS-версию, которая поставляется в комплекте и по определению работать должна. Но в этот раз что-то пошло не так…
                          0
                          Оригинальный заявлено что не работает с 10кой, но при этом с небольшой руганью он работает. А в чем выражается что не работает с 11ой?
                      0
                      Igor_Le В сообществе есть идеи по выводу в логи рекомендательных сообщений по оптимизации PostgreSQL?
                      Например:
                      PostgreSQL упирается в диск — нужно установить диск/хранилище побыстрее
                      PostgreSQL не хватает памяти work_mem — нужно увеличить work_mem
                      Структура вашей таблицы/бд неоптимальна — лучше примените другую структуру
                      и т.п. и т.д.
                        0
                        Насколько мне известно, пока лишь робкие попытки поднять этот вопрос. В ближайшее время вряд ли что изменится.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое