Полгода на PostgreSQL 18 в проде: замеры по async I/O, uuidv7 и pg_upgrade без боли

[madsegfault]

Обещал коллегам по цеху отписаться по итогам — выполняю. В декабре перевели основную базу (~1.4 ТБ, днём OLTP, ночью тяжёлая аналитика) с PG 15 сразу на 18, минуя промежуточные. Хайлайты.

1. Сам апгрейд. pg_upgrade --link отработал с даунтаймом 4 минуты. Главный подарок восемнадцатки: статистика планировщика теперь переезжает вместе с кластером. Не нужно после апгрейда судорожно гнать vacuumdb --analyze-in-stages и первые часы ловить кривые планы — для нас это всегда было самой стрёмной частью.

2. Async I/O, ради которого всё затевалось. По умолчанию io_method = worker, мы на голом железе с ядром 6.8 включили io_uring. Замеры:
- ночные аналитические выборки с seq scan по холодным данным: минус 35-40% времени
- bitmap heap scan тоже заметно бодрее
- дневной OLTP: разница в пределах погрешности, 2-3%

3. uuidv7(). Выкинули расширение, новые таблицы — на v7. Индексы по PK перестали пухнуть: btree по таблице на 200 млн строк примерно на 30% компактнее аналогичного старого на v4, вставка ровнее, страницы не дробятся随 случайным ключом.

Из неприятного: на одной реплике словили подозрительный рост памяти у io-воркеров, лечился рестартом, после минорного обновления не повторялся.

Кто ещё на 18 в проде? Особенно интересен опыт в облаках на сетевых дисках.

[clickhousefan]

Спасибо за цифры, дополню по io_uring, потому что мы на эти грабли встали всей командой. В Kubernetes и Docker дефолтный seccomp-профиль режет нужные сисколлы — неделю не могли понять, почему с io_method = io_uring постгрес не стартует, хотя на соседней виртуалке всё летает. Варианта два: кастомный seccomp-профиль или оставаться на worker. И помните, что io_uring требует ядро от 5.1, а на корпоративных дистрибутивах с древними ядрами остаётся только worker — впрочем, он тоже ощутимо лучше старой синхронщины.

[redis_guru]

Все эти проценты прекрасны, но катить .0-версию в первый же квартал — смело, снимаю шляпу. Мы по старинке дотерпели до 18.3 и только сейчас едем. Хотя за переносимую статистику в pg_upgrade двумя руками плюс — это напрашивалось лет десять, теперь мажорные апгрейды наконец перестали быть событием с поседением.

[maja33]

@omnicrom, Раз пошла такая пьянка — не пропустите темпоральные ограничения, WITHOUT OVERLAPS. Всякие брони, тарифные сетки, интервалы действия скидок теперь валидируются декларативно на уровне БД. Мы выпилили два самых страшных триггера в проекте, каждый на полстраницы plpgsql с ручными блокировками, и заменили одной строкой в PRIMARY KEY. Ревью такого кода — отдельное удовольствие.

[taichi]

А skip scan кто-нибудь пощупал? Делюсь: у нас составной индекс (tenant_id, created_at) и пачка отчётных запросов без tenant_id в условии. На 17 они уходили в полный скан, на 18 планировщик стал ходить skip scan-ом по тому же индексу — три запроса из топа pg_stat_statements просто исчезли из медленных. Ноль переписанного кода, ноль новых индексов. Самая недооценённая фича релиза, имхо.

[ransome]

По uuidv7 добавлю ложку дёгтя, раз все такие довольные. Он по спецификации раскрывает время создания записи — первые 48 бит это таймстемп. Если светить такие ID наружу как номера заказов, конкурент по разнице идентификаторов читает ваши объёмы за период, а по таймстемпам — динамику по часам. Мы у себя сделали так: внутри везде v7 ради компактных индексов, наружу — отдельный непрозрачный публичный код. Дёшево и спится спокойнее.

[omnicrom]

Подтверждаю наблюдение про облака. Managed-постгрес у российских облачных провайдеров io_method крутить пока не даёт, а вот на self-hosted ВМ с network-ssd как раз самый жирный выигрыш: латентность сетевого диска высокая, и асинхронные чтения её красиво прячут. На локальных NVMe с горячим кешем разница около нуля, что физически логично. Так что ответ на вечный вопрос «буст или плацебо» — смотря насколько медленные у вас диски и холодные данные.