Dalibo, bir müşterilerinin PostgreSQL sorgusunun toplu işlem sonrası ilk çalıştırmada çok yavaş, sonraki çalıştırmalarda ise hızlı olduğunu bildirmesiyle ilginç bir optimizasyon davranışı keşfetti. Başlangıçta önbellekleme veya ANALYZE eksikliği şüphesiyle yaklaşıldı. Ancak müşteri, pg_stat_user_tables verilerine göre tabloların yavaş ve hızlı çalıştırmalar arasında VACUUM veya ANALYZE edilmediğini belirtti. Bu durum, Dalibo ekibini şaşırttı ve konuyu derinlemesine incelemeye yöneltti.
İnceleme sonucunda, aynı sorgunun ilk çalıştırmasında Merge Right Join düğümünü içeren bir sorgu planı kullanıldığı ve bu planın 89 saniyeden fazla sürdüğü görüldü. Özellikle foo tablosundaki Index Scan işlemi çok yüksek maliyet ve süreye sahipti. İkinci çalıştırmada ise sorgu planı tamamen değişmiş ve sadece milisaniyeler içinde tamamlanmıştı. Bu durum, ANALYZE yapılmamasına rağmen PostgreSQL sorgu planlayıcısının neden farklı planlar seçtiği ve Merge Join düğümünün ilk çalıştırmada neden bu kadar performans sorununa yol açtığı sorusunu gündeme getirdi. Bu vaka, veritabanı optimizasyonunun karmaşıklığını ve beklenmedik davranışlarını gözler önüne seriyor.
PostgreSQL sorgu planlayıcısının, `ANALYZE` istatistikleri güncellenmese bile farklı çalıştırmalarda radikal biçimde farklı ve performanslı sorgu planları seçebilmesi, veritabanı optimizasyonunun derinliklerini ve potansiyel tuzaklarını ortaya koyuyor.