PostgreSQL 18 в проде: прыжок с 15-й, io_uring и сюрприз с Docker

[tavogo]

Доехали наконец: перевели основной кластер с PostgreSQL 15 на 18.3, прыжок через два мажора. База 1,4 ТБ, пик около 9000 TPS, физическая реплика плюс логическая в аналитику (она у нас в ClickHouse). Делюсь, что получили и где споткнулись.

Апгрейд: pg_upgrade --link --jobs=8, суммарный даунтайм четыре минуты. Главный подарок 18-й — статистика планировщика теперь переезжает вместе с кластером: ANALYZE-шторма после апгрейда не было, прод сразу работал на нормальных планах. Кто апгрейдил мажоры раньше — поймёт, насколько это меняет жизнь.

Асинхронный ввод-вывод: по умолчанию io_method = worker, мы включили io_uring. На холодных seq scan и вакууме ускорение в 1,6–1,8 раза, на горячем OLTP разницы почти нет, что логично. И вот тут сюрприз: в Docker постгрес с io_method = io_uring просто не стартует — дефолтный seccomp-профиль режет нужные syscall'ы. Лечится кастомным профилем, но мы в итоге вынесли постгрес из контейнера, ему там и не место было.

uuidv7(): новые таблицы перевели с v4 — вставки перестали колотить случайные страницы PK-индекса, write amplification по pg_stat_io упал заметно. Skip scan тоже порадовал: составной индекс (tenant_id, created_at) теперь работает и для запросов без tenant_id в WHERE, выкинули дублирующий индекс на 40 ГБ.

Из вопросов: кто-нибудь гонял io_uring на ядрах постарше? У нас Ubuntu 24.04, ядро 6.8, а про старые ядра слышал разное.

[jbosco]

Завидую тем, у кого свои железки. На managed-постгресе в облаках до io_method не дотянуться вообще, а с версиями лотерея: у одних 18-я уже доступна, у других максимум 17-я. Мы из-за этого до сих пор без skip scan, хотя ровно наш кейс — мультитенантные составные индексы. Подумываем о переезде на свои ВМ именно по этой причине: разница в цене уже не оправдывает связанные руки.

[cpp2]

@tavogo, По uuidv7 встряну. Он решает фрагментацию, но не размер: 16 байт против 8 у bigint. На таблице в два миллиарда строк это плюс 15 ГБ только на первичный ключ, и каждый вторичный индекс тоже толще. Мы остались на bigint generated always as identity внутри, а публичный uuid наружу — только там, где идентификатор утекает в API.

Но честно скажу, где uuidv7 безальтернативен: мерж данных из нескольких источников и шардирование. Если такое в планах — берите сразу, переезжать потом больно.

[archenjoyer]

Дополню цифрами со своего стенда, мерили перед таким же апгрейдом. Железо: NVMe RAID10, 128 ГБ RAM, ядро 6.8. Seq scan холодной таблицы на 40 ГБ: sync — 1,9 ГБ/с, worker с дефолтными io_workers=3 — 3,1 ГБ/с, io_uring — 3,4 ГБ/с. Подняли io_workers до восьми — worker почти догнал io_uring. Так что если контейнеры и seccomp вам дороги, worker с подкрученными воркерами — совершенно рабочий вариант.

Ещё не пропустите: effective_io_concurrency в 18-й по умолчанию 16 вместо 1. Если вы его руками занижали под старые диски — пересмотрите, на NVMe это даром отдаёт приличный кусок на bitmap scan.

И про вакуум: с асинхронным чтением он ощутимо быстрее добегает до конца больших таблиц, у нас окно обслуживания сократилось с пятидесяти минут до получаса.

[ansible777]

Подскажите по расширениям: pgvector, pg_stat_kcache, timescale под 18-й живут? Мы в прошлый раз год сидели на старом мажоре из-за одного несовместимого расширения, теперь дую на воду.

[mjp1982]

pgvector свежий собирается и работает без вопросов. Timescale поддержку 18-й завезли в осенних релизах, но проверяйте свою версию — у них поддержка новых мажоров исторически идёт с лагом. Главная засада — самописные C-расширения: в 18-й много двигали вокруг подсистемы ввода-вывода, у нас одно внутреннее расширение пересобиралось с правками. Поднимите стейдж и прогоните регресс до прода: час работы — спокойный сон.