JIT (з PostgreSQL 11, увімкнено за замовчуванням з 12) компілює частини виконання запиту - обчислення виразів у WHERE, агрегатів, розбір рядків - у машинний код через LLVM. Замість інтерпретації виразу для кожного рядка виконується скомпільований код.
Де допомагає: довгі аналітичні запити, що обробляють мільйони рядків зі складними виразами й агрегатами. Виграш - десятки відсотків часу виконання.
Як вирішується, чи вмикати: за оцінною вартістю запиту.
jit_above_cost(100 000) - вмикати JIT для запитів, дорожчих за це значення;jit_inline_above_cost,jit_optimize_above_cost(500 000) - вмикати вбудовування й агресивну оптимізацію.
Чому JIT часто вимикають на OLTP-серверах:
- Компіляція займає час - десятки чи сотні мілісекунд. Для запиту, що сам виконується за 50 мс, JIT робить його втричі повільнішим.
- Помилкові оцінки: якщо планувальник переоцінив кількість рядків (застаріла статистика, складні умови), вартість перевищує поріг, і JIT вмикається для запиту, якому він не потрібен. Так з'являються «дивні» запити, що іноді виконуються на 200 мс довше без видимої причини.
- Компіляція на кожне виконання: скомпільований код не кешується між запитами.
Як побачити в плані:
JIT:
Functions: 18
Timing: Generation 2.1 ms, Inlining 45.3 ms, Optimization 98.7 ms, Emission 60.2 ms, Total 206.3 ms
Execution Time: 248.9 ms
Тут на JIT пішло понад 80% часу запиту.
Що роблять:
ALTER SYSTEM SET jit = off; -- для типового веб-застосунку
ALTER ROLE analytics SET jit = on; -- лишити для аналітики
або піднімають пороги jit_above_cost, щоб JIT вмикався лише для справді важких запитів.
Висновок: як і JIT у PHP, у PostgreSQL він корисний для обчислювально важкої аналітики й мало допомагає типовому вебу з короткими запитами.
