PostgreSQL 18: як асинхронне введення-виведення змінює продуктивність бази даних

PostgreSQL 18 змінює роботу зі сховищем завдяки новій підсистемі асинхронного введення-виведення. Вона дозволяє базі надсилати кілька операцій читання паралельно, але реальний виграш залежить від запиту, методу AIO, операційної системи та самого накопичувача.

Асинхронне I/O прибирає частину очікування

Раніше PostgreSQL значною мірою покладався на readahead операційної системи. Версія 18 краще враховує власні шаблони доступу й може паралельно ініціювати читання для послідовних і bitmap heap scan, а також vacuum. У тестах проєкту окремі сценарії показували приріст до трьох разів, але це не універсальна обіцянка для кожної бази.

Метод AIO треба вибирати вимірюванням

Параметр io_method дозволяє використовувати worker, io_uring або синхронну поведінку. Доступність і ефект залежать від платформи. Починайте з офіційно підтримуваної конфігурації, проганяйте репрезентативне навантаження та порівнюйте throughput, latency, CPU, queue depth і час очікування сховища.

Skip scan розширює користь складених індексів

PostgreSQL 18 може застосовувати B-tree skip scan, коли запит не задає рівність для одного або кількох початкових стовпців складеного індексу. Це здатне скоротити повне сканування, але не скасовує проєктування індексів. Планувальник обирає метод за статистикою та оціненою вартістю.

Розробники отримали UUIDv7 і новий RETURNING

Функція uuidv7() створює ідентифікатори, впорядковані за часом, що може покращити локальність вставок порівняно з випадковим UUIDv4. У RETURNING тепер можна звертатися до попередніх і нових значень для DML-операцій. Віртуальні generated columns обчислюються під час читання й стали типовим варіантом.

Оновлення має зміни безпеки й сумісності

Додано OAuth-автентифікацію через розширення, налаштування TLS 1.3 cipher suites і перевірку FIPS-режиму. MD5-автентифікацію оголошено застарілою; для парольного доступу проєкт рекомендує SCRAM. Нові кластери отримують checksums сторінок за замовчуванням, що треба врахувати під час pg_upgrade.

Перевірте міграцію на копії даних

1. оновіть поточну основну версію до останнього minor-релізу;
2. перевірте розширення, драйвери та пулери;
3. запустіть pg_upgrade –check;
4. виміряйте тривалість міграції та повернення статистики;
5. порівняйте плани критичних запитів;
6. перевірте резервне копіювання й реплікацію;
7. зафіксуйте план відкату до початку запису в новий кластер.

Оптимізація починається після базової перевірки

Не змінюйте одночасно версію, індекси, параметри пам’яті та сховище: інакше причину регресії буде важко знайти. Матеріал TechPulse про обслуговування індексів PostgreSQL допоможе відокремити структурні проблеми від ефекту AIO. Стаття про міграції схем без зупинки корисна для планування змін застосунку.

Першоджерело: офіційне оголошення PostgreSQL 18.