Сегодня, 29 сентября 2016 года, вышел новый релиз PostgreSQL, получивший номер 9.6. В нём содержится много весьма полезных фич, и нельзя не рассказать о них, тем более что вклад нашей компании в этот релиз существенен. Поэтому в этой статье мы расскажем о тех разработках Postgres Pro, которые вошли в сегодняшний релиз.

Производительность и мониторинг


Улучшение представления pg_stat_activity в части информации об ожидающих процессах (Amit Kapila, Ильдус Курбангалиев).
Ранее в pg_stat_activity ожидающими считались процесссы, висящие на тяжелых (heavyweight) блокировках. Теперь там видны также ожидания легких блокировок (lightweight locks) и buffer-pins (как это по-русски?). О разных видах блокировок в постгресе можно прочитать в статье Александра Короткова. Новая информация видна в колонках wait_event_type и wait_event. Подробную информацию об этом патче можно прочитать в нашем блоге и в документации.
Эффективное использование памяти при построении GIN-индексов. (Robert Abraham, Фёдор Сигаев).
Теперь при построении GIN-индексов более эффективно используется память, если ее выделено (maintenance_work_mem) более гигабайта. Детали — в списке рассылки.

Немедленное освобождение удаляемых страниц GIN-индексов (Jeff Janes, Фёдор Сигаев).
Удаляемые страницы теперь сразу попадают в список свободных, что помогает сократить объем базы. Полезно при не слишком частом вакууме. Подробности в списке рассылки.

Эффективная обработка мертвых узлов в GiST-индексах (Анастасия Лубенникова).
Если при индексном скане обнаруживается мертвый узел таблицы, то соответствующий ему узел индекса тоже будет сразу помечен как мертвый. При вставке в индекс занимаемое им место будет использовано. Подробности в списке рассылки.

Замена спинлоков на атомарные операции (Александр Коротков, Andres Freund).
Повышает вертикальную масштабируемость за счет более эффективной реализации блокировок. Подробности в статье Александра Короткова.

Оптимизация ожидания блокировок (Александр Алексеев).
Изменения в алгоритме ожидания блокировок, дающие заметный вклад на многопроцессорных серверах. Подробности в списке рассылки.

Улучшение производительности ResourceOwner (Александр Алексеев).
Линейный поиск заменен на нечто более эффективное. Подробности в списке рассылки.

Вычисление выражений в SELECT после ORDER и LIMIT, если это возможно (Konstantin Knizhnik).
Теперь, если результаты выражения не попадут в выдачу запроса и не участвуют в условиях выборки и группировки, оно не будет вычисляться. Это сокращает количество вызовов функций (возможно, тяжелых). Кроме того, вызов функций будет осуществляться в порядке, задаваемом ORDER BY, а иногда это важно. Подробности в списке рассылки.

Добавлены функции оценки селективности для contrib/intarray (Юрий Журавлев, Александр Коротков).
Это улучшает работу планировщика с запросами, в которых задействованы поля типа int[]. Подробности в списке рассылки.

Полнотекстовый поиск


Поиск фраз — новая возможность полнотекстового поиска (Фёдор Сигаев, Олег Бартунов, Дмитрий Иванов).
Подробности на слайдах и в документации полнотекстового поиска.

Парсер полнотекстового поиска теперь понимает лидирующие цифры в e-mail'ах и именах хостов (Артур Закиров).
Это помогает правильно индексировать тексты, содержащие e-mail'ы и урлы. Нужно перестроить tsvector'ы, сгенерированные с использованием предыдущей версии. Подробная информация о патче — в списке рассылки.

Поддержка словарей Hunspell и увеличение количества поддерживаемых языков (Артур Закиров).
Подробности в списке рассылки и в документации.

Новые полезные функции для работы с tsvector (Стас Кельвич).
Подробности в списке рассылки и в документации.

Функции ts_stat() и tsvector_update_trigger() теперь оперируют с данными бинарно совместимых типов (Фёдор Сигаев).
Подробности в списке рассылки.

Расширяемость и расширения


Добавлен класс операторов в SP-GiST для типа box (Александр Лебедев)
Подробности в списке рассылки.

Добавление опций в ALTER OPERATOR, позволяющих указывать функции селективности для операторов (Юрий Журавлев).
Подробности в списке рассылки.

Новая конструкция CREATE ACCESS METHOD, позволяющая создавать индексные методы доступа в расширениях PostgreSQL (Александр Коротков, Petr Jelinek).
Подробности на слайдах.

Упрощение API индексных методов доступа (Александр Коротков, Andrew Gierth).
API индексных методов доступа изменен, чтобы в большей соответствовать концепциям, используемым в FDW и Tablesample. Это упрощает C-шный код и облегчает создание новых методов доступа в устанавливаемые расширения. Количество колонок в системной таблице pg_am уменьшилось, и появились новые функции для доступа к параметрам методов доступа из SQL. Подробности на слайдах.

Добавлен обобщенный интерфейс для записи WAL (Александр Коротков, Petr Jelinek, Markus Nullmeier).
Это позволяет расширениям стандартизованным образом делать записи в WAL. Это позволяет расширениям определять свои типы индексов, которые автоматически будут поддерживаться механизмом WAL-логов, т.е., в частности, реплицироваться потоковой репликацией. Подробности на слайдах.

Классы операторов SP-GiST operator classes теперь могут сохранять некоторое значение (“traversal value”) в процессе обхода индекса (Александр Лебедев, Фёдор Сигаев).
Подробности в списке рассылки.

Новый модуль contrib/bloom реализует метод индексного доступа на основе блумовской фильтрации (Фёдор Сигаев, Александр Коротков).
Модуль написан, в основном, для проверки новых возможностей по определению методов доступа в расширениях, но может оказаться полезным в реальных многоколоночных запросах. Подробности на слайдах.

В расширении contrib/cube введен оператор расстояния для кубов и поддержка kNN-поиска для GiST-индексов по колонкам типа cube (Стас Кельвич)
Подробности в списке рассылки.

Разное


В срезе массива теперь можно не указывать левую или правую границу (Юрий Журавлев)
Например, array_col[3:]. Подробности в списке рассылки.

Улучшение pg_rewind: возможность работы с измененной целевой линией времени (Александр Коротков)
Это позволяет, например, откатить бывшую реплику к состоянию старого мастера. Подробности в списке рассылки.

Улучшения модуля pageinspect (Николай Шаплов)
Функция heap_page_items() модуля contrib/pageinspect’s показывает сырые данные записи. Новые функции tuple_data_split() и heap_page_item_attrs() позволяют заглянуть внутрь индивидуальных полей.
Подробности на слайдах.

Добавлена поддержка “похожести слов” в модуле contrib/pg_trgm (Александр Коротков, Артур Закиров)
Можно измерить степень похожести между строкой и наиболее похожим на нее словом другой строки.
Подробности в списке рассылки.

В модуле contrib/pg_trgm добавлен параметр конфигурации pg_trgm.similarity_threshold (Артур Закиров)
Порогом похожести теперь можно управлять через конфигурационный параметр. Раньше это делалось только через специальные функции set_limit() и show_limit(). Подробности в списке рассылки.


Если читателям будут особо интересны какие-то из этих пунктов, мы с удовольствием напишем подробнее.
Поделиться с друзьями
-->

Комментарии (16)


  1. format1981
    29.09.2016 22:28
    +5

    Вы молодцы. Спасибо, за ваш вклад.
    Очень хотелось бы почитать про новые возможности полнотекстового поиска.


    1. zen
      29.09.2016 22:52
      +2

      Вот здесь можно посмотреть http://www.sai.msu.su/~megera/postgres/talks/pgopen-2016-rum.pdf и ранняя версия доклада http://www.sai.msu.su/~megera/postgres/talks/pgcon-2016-fts.pdf


      1. format1981
        29.09.2016 23:50
        +3

        Спасибо


  1. ZOXEXIVO
    29.09.2016 23:23
    +4

    Про CoreServer ничего говорить не стану — все на высоте.
    А вот новая pgAdmin 4, которую разрабы делали 10.000 часов и применили JQuery, выглядит очень стремно — лучше бы не пытались. Даже иконки не поменяли — перетянули с 3 версии.


    1. Unsacrificed
      30.09.2016 00:35
      +6

      Поддержу по поводу pgAdmin 4. Я надеялся, что третью версию просто перепишут на какой-нибудь современный кроссплатформенный gui (qt5 или gtk3 например). Третья версия, как по мне — почти идеал, вот только проблемы на mac и на hidpi. Но то, что там сотворили в четвертой — просто ужасно. Пробовал последнюю предрелизную бету (или как там она называлась) — баги лезли буквально с первой секунды работы. Знаю, что сейчас вышла релизная, еще не пробовал ее, но то количество багов, по-моему, просто нереально было исправить за такой короткий срок. Да и сама идея делать клиентские приложения для PC на технологиях web'а меня удручает.


      1. x-wao
        30.09.2016 00:37
        +1

        Тем не менее, тенденция именно такова. Это проще и дешевле…


    1. dbax
      30.09.2016 20:41

      Ужасное поделие…
      Грузится минут 5, инструмент по управлению сессиями урезали (он их просто отображает без возможности прибить). Как может быть админский инструмент без этого?


  1. shishmakov
    30.09.2016 00:03
    +1

    Будет ли краткий синтаксис добавления новых элементов в JSONB на замену jsonb_set? Оператором #- можно удобно произвести удаление элемента на любой вложенности документа, хотелось бы такой же краткости с || (или новым #+).


    1. x-wao
      30.09.2016 00:38

      Многие этого давно хотят! Так что будет.


  1. Envek
    30.09.2016 09:49
    +2

    Круто, спасибо!


    Расскажите, пожалуйста, чуть подробнее (по русски и может чуть более простым языком) о:


    Вычисление выражений в SELECT после ORDER и LIMIT, если это возможно


    1. smagen
      30.09.2016 15:27
      +3

      Вот простой пример.

      SELECT random() r, pg_sleep(1) FROM generate_series(1,10) ORDER BY r LIMIT 1;
      

      В 9.5 и ниже pg_sleep() будет вычислены до того, как будет выполнен ORDER BY и LIMIT. Поэтому запрос длится чуть больше 10 секунд.
      В 9.6 pg_sleep() будет выполнен после ORDER BY и LIMIT, поэтому запрос будет длиться чуть больше одной секунды.


  1. Envek
    30.09.2016 09:52

    Напишите ещё, пожалуйста, о планах выпуска вашего дистрибутива, Postgres Pro 9.6 и поддержки 9.6 в ваших расширениях (меня очень сильно pg_pathman привлекает, сейчас обновляемся с 9.4 на 9.5 именно из-за него, хотели бы и сразу на 9.6 прыгнуть).


  1. VtD
    30.09.2016 13:17
    +1

    По поводу выполнения функций после ORDER and LIMIT: а что если в отсекаемой части вычислений будет ошибка? Деление на ноль, например. Верно ли понимаю, что раньше оно бы не дало вернуть результаты, а в 9.6 не помешает и результаты появятся?

    Попробовал на 9.5 сейчас сделать деление на ноль, которое выскакивало бы только после LIMIT-а, но видимо запрос был слишком простым и вычисления не проводились.


    1. smagen
      30.09.2016 15:35
      +1

      Вот пример с делением.

      CREATE OR REPLACE FUNCTION slow_div(bigint, bigint) RETURNS bigint AS
      $$
        BEGIN
          RETURN $1 / $2;
        END;
      $$ LANGUAGE plpgsql COST 1000;
      SELECT slow_div(1, 10 - g) FROM generate_series(1,10) g ORDER BY g LIMIT 1;
      

      Для того, чтобы постгрес отложил вычисление функции, нужно ей cost по-больше задать.
      На 9.5 этот запрос у меня возвращает ошибку «division by zero», в 9.6 успешно возвращает одну строку.


  1. RedFast
    30.09.2016 20:42
    +3

    Ребят вы молодцы, статья просто супер. Работал ранее на MongoDB, перешел на Postgres и не жалею ни капли.
    Спасибо за ваш труд.


  1. the_unbridled_goose
    03.10.2016 14:51
    +2

    Спасибо Вам большое за Ваш вклад! Новые фичи просто огонь, особенно для полнотекстового поиска.