PostgreSQL 18 Skip Scan дає прискорення у 21 раз на Aurora

Кожен, кого будили о 3 ночі через те, що складений індекс перестав відповідати шаблону WHERE, добре знайомий із цією проблемою. PostgreSQL 18 щойно скоротив час виконання показового запиту з 73.2 мс до 3.4 мс на тому самому залізі — покращення у 21 раз — без додавання жодного нового індексу. Це головна цифра від AWS цього тижня, і вона змінює підхід до проектування B-tree структур для багатьох команд.

Цифри

Налаштування тесту гранично просте, що якраз і робить його переконливим. Як повідомив Amazon Web Services (AWS), бенчмарк запускався на інстансі db.r6g.large — скромному ARM-сервері, який багато команд використовують у staging та невеликих продакшн-середовищах. Таблиця містила мільйон рядків у схемі customer_orders зі складеним індексом на (status, created_date). Колонка status мала рівно 5 унікальних значень. Обидва запуски виконувалися з прогрітим кешем буферів, тому це не трюк з I/O.

На Aurora PostgreSQL 17.10 планувальник діяв так, як завжди, коли провідна колонка відсутня у WHERE: він переходив до Parallel Seq Scan із 2 запланованими та 2 запущеними воркерами. Було прочитано 7 353 спільних блоки. Кожен цикл воркера відфільтровував 332 433 рядки. Час планування — 0.091 мс, час виконання — 73.200 мс.

На Aurora PostgreSQL 18.4, той самий інстанс, ті самі дані, той самий запит із фільтром created_date = '2026-03-15', планувальник переключився на Bitmap Index Scan по складеному індексу. Було виконано 11 звернень до індексу — по одному на кожне унікальне провідне значення плюс накладні витрати — і прочитано 2 266 спільних блоків. Час планування — 0.065 мс. Час виконання — 3.374 мс.

Кількість блоків скоротилася приблизно на 69%. Час виконання — приблизно на 95%. Це і є показник у 21 раз, і такі цифри самі по собі окупають міграцію.

Що це означає в операційному контексті? Запит, який виконується 500 разів на секунду на завантаженому checkout-сервісі, повертає вам приблизно 35 секунд CPU-часу на кожну реальну секунду по всьому кластеру. Для гарячого розрахункового сервісу iGaming це різниця між необхідністю масштабувати writer і відсутністю такої потреби. Я бачив продакшн-інциденти, коли команди передчасно шардували сервіс, бо одне обмеження планувальника виглядало структурним. Ним воно не було. До вирішення залишалась одна версія.

Моя думка: деталь про 5 унікальних значень — це те, що варто засвоїти. Skip scan дає великий виграш, коли провідні колонки мають низьку кардинальність. Зі зростанням кардинальності 11 звернень до індексу перетворюються на 11 000, і математика змінюється.

Що насправді нового

Чотири пункти першої частини серії від AWS — це оптимізація skip scan для багатоколонкових B-tree індексів, розширений вивід EXPLAIN, що розкриває поведінку сховища, автоматичне видалення зайвих self-join'ів та покращення vacuum/autovacuum. Друга частина охоплюватиме зміни в безпеці, моніторингу, для розробників та в логічній реплікації. Це великий обсяг змін, але саме skip scan переосмислює підхід до проектування схем.

Ось що змінилося під капотом. У PostgreSQL 17 і раніше багатоколонковий індекс на (a, b) міг використовуватися лише тоді, коли WHERE посилався на a, або на a і b разом. Фільтрація лише по b залишала планувальнику два варіанти: послідовне сканування або створення окремого індексу лише по b. Команди створювали другий індекс. Потім третій. Потім приходив рахунок за write amplification.

Skip scan дозволяє планувальнику перебирати унікальні значення провідної колонки та звертатися до індексу для кожного з них. Документація PostgreSQL достатньо добре описує метод доступу B-tree, щоб механізм став інтуїтивно зрозумілим: замість «сканувати від провідного ключа» планувальник робить «для кожного унікального провідного ключа — сканувати». Одинадцять звернень до індексу в бенчмарку AWS безпосередньо відображають це: 5 унікальних значень status плюс граничні проби, потрібні виконавцю.

Розширений вивід EXPLAIN — це тихо друга за важливістю зміна. У плані версії 18 з'явився Index Searches: 11 як самостійний рядок. Це саме той сигнал, потрібний для виявлення неправильного використання skip scan під час code review або в журналі повільних запитів. Без такої видимості довелося б відновлювати стратегію з кількості буферів.

Збереження статистики оптимізатора між мажорними версіями — це непомітна, але важлива операційна зміна. Кожен, хто виконував мажорне оновлення Postgres, знає цей ритуал: перемикаємось, стежимо за дашбордами, чекаємо, поки плани не деградують через очищення pg_statistic, потім запускаємо ANALYZE о 2 ночі, молячись, щоб autovacuum не влаштував штурм. Збереження статистики між оновленнями усуває цілий клас інцидентів після переключення.

Автоматичне видалення self-join'ів — це приємна перемога на рівні компілятора для SQL, згенерованого ORM. Покращення Vacuum важливі для тих, хто обслуговує таблиці з інтенсивним оновленням. Жодне з них не настільки значуще, як skip scan.

Що вже враховано для інженерних команд

Більшість досвідчених Postgres-команд і так очікували, що PG18 принесе skip scan. Це обговорювалося у списку розсилки -hackers роками, а Oracle і SQL Server мають аналогічні механізми вже десятиліття. Що вже враховано: функція існує, вона працює для провідних колонок із низькою кардинальністю, і не врятує вас при високій кардинальності. Жодна розумна людина не буде прибирати свої btree_gin-індекси тільки на підставі запису в блозі.

Що ще не враховано — принаймні, з огляду на розмови з провідними фахівцями платформ — це масштаб можливого очищення індексів. Багато продакшн-схем несуть два, три, чотири «про всяк випадок» одноколонкових індекси, які були додані саме тому, що складений індекс не покривав певний шаблон запиту. Кожен такий індекс коштує пропускної здатності запису та обсягу WAL при кожному INSERT і UPDATE. Skip scan дозволяє деякі з них видалити.

Незручна правда: більшість команд не виконають це очищення. Вони перейдуть на PG18, залишать усі наявні індекси і просто отримають виграш від skip scan як бонусну продуктивність на запитах, які й так працювали нормально. Команди, які проведуть аудит списку індексів і видалять зайві, — ось хто побачить виграш на стороні запису, а ці виграші, як правило, більші, ніж заголовна цифра на стороні читання за квартал.

Також варто відзначити: часові рамки Aurora та RDS тут збігаються, що буває не завжди. Обидва сервіси вже підтримують PG18. Командам на RDS не потрібно чекати цілий цикл релізів позаду Aurora.

Контраріанський погляд

Skip scan — небезпечний інструмент у невмілих руках. Бенчмарк AWS використовував 5 унікальних значень статусу, що близько до ідеального випадку. Застосуйте ту саму оптимізацію до провідної колонки з мільйоном унікальних значень, і планувальник витратить CPU на звернення до індексу там, де послідовне сканування завершилося б швидше. Передбачається, що планувальник має виходити з цього через cost-модель, але cost-моделі планувальника відомо своїм оптимізмом на синтетичних даних і песимізмом на реальних.

Другий контраріанський кут: розширений вивід EXPLAIN спричинить хвилю тікетів «чому мій запит тепер повільний». Команди, які раніше не бачили Index Searches у своїх планах, почнуть бачити великі числа і панікувати. Очікуйте сплеску запитань на Stack Overflow і багатьох передчасних налаштувань індексів.

По-третє, функція «статистика зберігається між мажорними оновленнями» змусить деякі команди пропустити вікно валідації після оновлення. Це вікно існує з причин, що виходять за межі pg_statistic. Не скорочуйте свій canary-період лише тому, що один клас регресій став простішим.

Ключові висновки

• PostgreSQL 18 skip scan перетворив паралельне послідовне сканування за 73.2 мс на bitmap index scan за 3.4 мс у бенчмарку AWS — прискорення у 21 раз на db.r6g.large з мільйоном рядків.
• Виграш найбільший, коли провідна колонка складеного індексу має низьку кардинальність. П'ять унікальних значень дали 11 звернень до індексу. Провідні колонки з високою кардинальністю не дадуть такого результату.
• Проведіть аудит списку індексів після оновлення. Реальна перевага — у видаленні надлишкових одноколонкових індексів, які були додані лише для обходу старого обмеження планувальника, що скоротить write amplification та обсяг WAL.
• Збереження статистики оптимізатора між мажорними версіями усуває поширену причину регресій планів після переключення, але не використовуйте це як привід скорочувати canary-вікно.
• Розширений вивід EXPLAIN тепер відображає Index Searches як метрику першого класу. Додайте її до своїх дашбордів повільних запитів заздалегідь.