Planner tahminle karar verir
PostgreSQL her sorguda tüm olasılıkları gerçek veride deneyip en hızlısını seçmez. İstatistiklere, tablo büyüklüğüne, indeks bilgisine ve maliyet ayarlarına bakarak tahmin yapar. Tahmin yanlışsa plan da yanlış görünebilir.
Bu yüzden EXPLAIN çıktısında en önemli sinyallerden biri estimated rows ile actual rows farkıdır. Tahmin 100 satır, gerçek 2 milyon satırsa planner başka bir dünya varsaymış demektir.
- İstatistikler eskiyse ANALYZE gerekir.
- Veri dağılımı çok dengesizse varsayılan istatistik hedefi yetmeyebilir.
- Fonksiyonlu WHERE koşulları indeks kullanımını zorlaştırabilir.
- Tenant bazlı uçurumlar plan kararlılığını bozabilir.
EXPLAIN’i süre kadar tahmin farkı için okuyun
EXPLAIN ANALYZE BUFFERS çıktısı yalnızca sorgu kaç milisaniye sürdü diye okunmamalıdır. Hangi adım kaç satır bekledi, kaç satır gördü, diskten mi bellekten mi okudu ve en çok zaman nerede harcandı soruları daha değerlidir.
Bu okuma yapılmadan indeks eklemek bazen sorunu çözmez, sadece yazma maliyetini artırır.
Planı kanıtla okuma
explain (analyze, buffers, verbose) select * from orders where tenant_id = 42 and status = 'paid' and created_at >= now() - interval '7 days' order by created_at desc limit 50;
İstatistikleri tazelemek bazen indeksten önce gelir
Tabloya çok veri eklendiyse veya dağılım değiştiyse planner hâlâ eski dünyaya göre karar veriyor olabilir. Bu durumda önce ANALYZE çalıştırmak ve autovacuum/analyze ayarlarının yeterli olup olmadığını kontrol etmek gerekir.
Çok dengesiz kolonlarda daha yüksek statistics target gerekebilir. Örneğin status alanında kayıtların yüzde 99’u paid, yüzde 1’i failed ise varsayılan örneklem bazı ayrımları yeterince iyi yakalayamayabilir.
İstatistik kontrolü
analyze orders;
select attname, n_distinct, most_common_vals, most_common_freqs
from pg_stats
where schemaname = 'public'
and tablename = 'orders'
and attname in ('tenant_id', 'status');Planı zorlamak yerine sorguyu anlatılır hale getirin
PostgreSQL’de planı zorla değiştirmeye çalışmak yerine çoğu zaman sorguyu ve indeksleri planner’ın anlayacağı hale getirmek daha sağlıklıdır. Fonksiyonlu filtreleri sadeleştirmek, doğru composite index kurmak ve gereksiz SELECT * kullanımını azaltmak işe yarar.
En iyi performans iyileştirmesi, sorgunun gerçek kullanım desenini bilen uygulama ekibiyle veritabanı çıktısını aynı masaya koyduğunuzda çıkar.