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

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

Введение

Привет, Хабр!

Хочу поделиться опытом написания миграций для postgres и django. Речь в основном пойдёт про postgres, django же здесь хорошо дополняет, так как из коробки имеет автоматическую миграцию схемы данных по изменениям модельки, то есть имеет довольно полный список рабочих операций по изменению схемы. Django можно заменить на любой любимый фрэймворк/библиотеку — подходы скорее всего будут похожи.

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

Перед тем как пойти дальше позволю себе сделать следующие предположения.

Можно разделить логику работы с базой данных большинства приложений на 3 части:

1. Миграции — изменение схемы базы данных (таблиц), предположим мы всегда запускаем их в один поток.
2. Бизнес логика — непосредственная работа с данными (в пользовательских таблицах), работает с одними и теми же данными постоянно и конкурентно.
3. Миграции данных — не изменяют схемы данных, работают по сути как бизнес логика, по умолчанию, когда будем говорить про бизнес логику, будем также подразумевать и миграции данных.

Даунтайм — это состояние, когда часть нашей бизнес логики не доступна/падает/грузится на заметное для пользователя время, предположим это пару секунд.

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

Релизы

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

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

15 сентября в Авито прошёл митап, на котором мы говорили о масштабировании приложений на PostgreSQL. Сегодня я хочу поделиться материалами с него — видеозаписями, презентациями от докладчиков, показать фото. Также под катом публикую разбор вопросов викторины, которую мы проводили здесь, на Хабре, перед митапом. И рассказываю о своих впечатлениях от встречи.

Осталось буквально несколько дней до новой встречи #RuPostgres. Она пройдёт уже в эту субботу, 15 сентября, в офисе Авито. Будем говорить о масштабировании приложений на PostgreSQL. Хорошие новости — у нас немного расширилась программа, и осталось ещё несколько свободных мест для слушателей. Присоединяйтесь. А ещё мои коллеги придумали мини-викторину, посвященную Postgres. Её мы проводим онлайн, поэтому принять участие могут все. Подробности под катом.

Использовать БД только для складирования данных — это всё равно, что назвать Unix интерфейсом для работы с файлами. Посему, хочу напомнить об известных и не очень функциях БД, которые хотелось бы чаще встречать в боевых веб-приложениях.

Мы начали обновлять в нашем сервисе мониторинг для PgBouncer и решили все немного причесать. Чтобы сделать всё годно, мы притянули самые известные методологии перформанс мониторинга: USE (Utilization, Saturation, Errors) Брендана Грегга и RED (Requests, Errors, Durations) от Тома Уилки.

Под катом рассказ с графиками про то, как устроен pgbouncer, какие у него есть конфигурационные ручки и как используя USE/RED выбрать правильные метрики для его мониторинга.