PostgreSQL 19, JIT derlemesini varsayılan olarak kapattı; analitik iş yükleri yeniden açmak zorunda

PostgreSQL 19, JIT derlemesi varsayılan olarak kapalı şekilde gelecek ve PostgreSQL 18'de açık olan bu ayarı tersine çevirecek. Değişiklik sürümde halihazırda mevcut; sürüm şu anda RC 1 aşamasında ve genel kullanıma sunulması 19 Kasım 2026 olarak planlandı. Bu, ağır analitik sorgular çalıştıran sitelerin JIT'i kendilerinin yeniden açması gerekeceği anlamına geliyor. Değişikliğin ayrıntılı bir anlatımı ve buna nasıl hazırlanılacağı Gabriel Anhaia tarafından dev.to'da yayınlandı.

Neler değişti

Bu değişiklik, Jelte Fennema-Nio tarafından yazılan ve Tomas Vondra tarafından 2 Nisan 2026'da push edilen bir commit'ten geliyor. dev.to yazısında alıntılanan commit mesajına göre temel sorun, bir sorgunun derlenip derlenmeyeceğine tek başına planner'ın maliyet tahmininin karar vermesi; yani bir tabloya birkaç satır fazladan eklenmesi gibi önemsiz bir olay, tahmini JIT eşiğinin hemen üstüne taşıyabiliyor. Milisaniyeler içinde tamamlanan bir sorgu, kimse sorguya dokunmamışken süresinin büyük kısmını yürütme yerine derlemeye harcayabilir hale geliyor.

Yazıda atıf yapılan PostgreSQL sürüm notları, maliyet temelli tetiklemeyi güvenilmez olarak tanımlıyor ve çok sayıda büyük analitik sorgu çalıştıran dağıtımların artık JIT'i elle etkinleştirmesi gerektiğini belirtiyor. Commit ayrıca, tüm hyperscaler'lar dahil olmak üzere büyük dağıtımların çoğunun zaten JIT kapalı şekilde çalıştığına dikkat çekiyor.

Eski varsayılan nasıl çalışıyordu

Postgres JIT, LLVM üzerinden iki şeyi derliyor: WHERE koşullarını, aggregate'leri ve projection'ları kapsayan ifade değerlendirmesi (expression evaluation) ve diskteki bir satırı bellekteki haline dönüştüren tuple deforming. Yalnızca LLVM desteğiyle derlenmiş sunucularda mevcuttur.

Derlemenin tetiklenip tetiklenmeyeceğine, plan zamanında üç eşik üzerinden karar veriliyor: jit_above_cost 100.000 ile hiç derleyip derlemeyeceğini, jit_inline_above_cost ve jit_optimize_above_cost ise 500.000'er ile fonksiyon inlining'i ve pahalı LLVM optimizasyon geçişlerinin çalıştırılmasını belirliyor. Bu eşikler 19'da değişmedi. Değişen şey jit ayarının kendisi; on'dan off'a geçiyor, yani eşikler yalnızca bir yönetici JIT'i yeniden açtığında tekrar anlam kazanıyor.

Yükseltmeden önce hazırlanacak iki liste

dev.to yazısının merkezindeki tavsiye, yükseltmeye başlamadan önce iş yükünüzü iki gruba ayırmanız. İlki, JIT'in zarar verdiği sorgular; bunlar 19'da bedavaya hızlanıyor. İkincisi, JIT'in yardım ettiği sorgular; bunlar harekete geçmediğiniz takdirde yavaşlayabilir.

SHOW jit; ile başlayın. Zaten off raporlıyorsa bu varsayılan değişikliği sizin için hiçbir şey yapmaz. On raporluyorsa, şüpheli bir sorguda EXPLAIN ANALYZE, derleme tetiklendiğinde bir JIT bloğu basıyor; LLVM'in kaç fonksiyon ürettiğini ve generation, inlining, optimization ve emission arasında bir süre dökümünü gösteriyor. Yazıda alıntılanan resmi dokümantasyondaki bir örnekte, JIT 7.416 ms'lık bir yürütmenin 7.104 ms'ını oluşturuyor; aynı sorgu JIT olmadan 0.365 ms'de çalışıyor.

Filo geneli bir görünüm için pg_stat_statements, derlenen fonksiyon sayısının yanı sıra generation, inlining, optimization ve emission için dört milisaniyelik zaman sütunu sunuyor. Yazı, bu sütunların PostgreSQL 18 için belgelendiğini, yani 19'da yeni olmadığını belirtiyor. Dört süreyi toplayıp statement'ları toplam JIT süresine göre sıralamak en çok ödeyenleri ortaya çıkarıyor; yazar ayrıca sıralamayı ortalama yürütme süresine göre yeniden çalıştırmayı öneriyor, böylece nadiren çalışan raporlama sorguları çok konuşkan statement'lar tarafından dışlanmıyor.

Bu sıralamadan iki örüntü çıkıyor. Ortalama yürütme süresi küçük ama JIT payı büyük olan sorgular eski varsayılanın kurbanları; çoğunlukla maliyet tahminleri eşiği aşacak şekilde kaymış OLTP tarzı statement'lar; bunlar 19'da basitçe kazanıyor. Ortalama süresi büyük ama JIT payı küçük olan sorgular ise risk: derleme çalışmaya göre ucuzdu ve derlenmiş ifadeler işlenen her satırda gerçek CPU işi tasarrufu sağlıyor olabilir.

Dikkat çekmeye değer bir uyarı: track_planning kapalıyken (varsayılan böyle) planlama süresi kaydedilmiyor ve JIT derleme süresi yürütme süresinin içinde görünüyor.

Yeni varsayılanı bugün test etmek

Davranışını önizlemek için PostgreSQL 19'a ihtiyacınız yok. 18'de SET jit = off bunu bir oturum için yeniden üretiyor; daha kapsamlı bir karşılaştırma, aynı betiği PGOPTIONS ortam değişkeniyle bir kez jit açık bir kez jit kapalı çalıştırıp gecikmeyi karşılaştıran pgbench ile yapılabilir. Yazı, özel betikler için -n bayrağını, karşılaştırmanın sorguyla ilgili kalması için tek client'ı, tekrarlı çalıştırmaları ve üretim boyutunda veriyle yüklenmiş bir staging replikasını öneriyor.

Neden önemli

Büyük bir veritabanı sürümündeki varsayılan değişikliği, operatörün hiçbir eylemi olmadan performansı değiştiriyor ve bu değişiklik iki yönüyle de kesiyor: kısa sorgular derleme vergisi ödemeyi bırakırken, uzun analitik sorgular yükseltmeden sonra sessizce gerileyebilir. Tüm büyük hyperscaler'ların JIT'i zaten kapatmış olması, maliyet modelinin pratikte geniş ölçüde hiç çalışmadığının güçlü bir sinyali. PostgreSQL 19'a geçmeyi planlayan her ekip JIT kullanımını şimdi denetlemeli; çünkü bunu yapmak için gereken kanıt, EXPLAIN çıktısında ve pg_stat_statements'ta halihazırda mevcut üretim sisteminin içinde duruyor.