Postgres 16 sorgu planlayıcısındaki yenilikler

PostgreSQL 16 sorgu planlayıcısındaki yenilikler

• PostgreSQL 16, sorgu planlayıcısına çok sayıda iyileştirme getiriyor; bu sayede birçok SQL sorgusu önceki sürümlere göre daha hızlı çalışıyor.
• Bu planlayıcı iyileştirmelerini PG16 sürüm notlarında görebilirsiniz, ancak her PostgreSQL sürümünde çok fazla değişiklik olduğundan her bir değişiklik için ayrıntılı açıklama vermek zor oluyor.
• Bu blog yazısı, PostgreSQL 16 sorgu planlayıcısında yapılan 10 iyileştirmeye derinlemesine bir analiz sunuyor; ayrıca PG15 ve PG16 planlayıcı çıktılarının karşılaştırmalarıyla birlikte nelerin değiştiğine dair örnekler veriyor.

PostgreSQL 16 sorgu planlayıcısındaki 10 iyileştirme

• Artımlı sıralama: PostgreSQL 13'te ilk kez sunulan artımlı sıralama, sonuç kümesinin bir kısmı zaten bir veya daha fazla öncü sütuna göre sıralanmışsa bundan yararlanarak yalnızca kalan sütunlar için sıralama yapar.
• Sıralı veriyi kullanan toplamalar: PostgreSQL 16 sorgu planlayıcısı artık satırları aggregate düğümüne sıralı biçimde sağlayan planlar oluşturmaya çalışır.
• Memoization: PostgreSQL 14'te ilk kez sunulan memoization plan düğümü, yinelenen değer aramalarını önlemek için bir önbellek katmanı gibi çalışır.
• Anti join: PostgreSQL 16, anti join yürütülürken daha küçük tablonun hash'lenmesine olanak tanır.
• Paralel hash join: PostgreSQL 16, FULL ve RIGHT join türleri için paralel hash join desteği sunar.
• Window function optimizasyonu: PostgreSQL 16, ROWS modu kullanıldığında RANGE moduna göre daha hızlı window function kullanımını mümkün kılar.
• Sürekli artan window function optimizasyonu: PostgreSQL 16, ntile(), cume_dist(), percent_rank() gibi window function'lara yönelik optimizasyonları genişletir.
• Bölümlenmiş tablolarda join kaldırma: PostgreSQL 16, partition table'larda LEFT JOIN kaldırma optimizasyonuna izin verir.
• DISTINCT sorgularında Limit kullanımı: PostgreSQL 16 sorgu planlayıcısı, tüm satırların aynı değeri içerdiğini algılayabildiğinde sonuçlarda tekilleştirme için bir plan düğümü eklemez.
• Merge Join için kuralların gevşetilmesi: PostgreSQL 16 sorgu planlayıcısı, Merge Join değerlendirilirken satırların sırasının tam olarak eşleşmesini istemek yerine en az bir öncü sütunun doğru şekilde sıralanmış olup olmadığını kontrol eder.

GN⁺ görüşü

• PostgreSQL 16'nın sorgu planlayıcısı iyileştirmeleri, veritabanı performansını artırmada önemli rol oynuyor. Özellikle artımlı sıralama ve memoization gibi özellikler, karmaşık sorguların daha verimli çalışmasını sağlıyor.
• Bu iyileştirmeler, PostgreSQL kullanan geliştiriciler ve veritabanı yöneticileri için çok faydalı olacak; özellikle büyük ölçekli verilerle çalışan sistemlerde performans artışı hissedilebilir.
• PostgreSQL topluluğunun sürekli yenilik ve iyileştirme çabası, açık kaynak veritabanı teknolojilerinin gelişimini ileri taşıyor ve bu da kullanıcılara ve şirketlere daha iyi veri yönetimi çözümleri sunuyor.

[GN⁺]

Hacker News görüşü

• Postgres sorgu planlayıcısının yürütme sırasında sorguyu yeniden planlayabilmesinin iyi olacağı yönünde bir görüş var. Veri dağılımına dair bilginin yetersiz olması verimsiz sorgu planlarının kurulmasına yol açabiliyor ve bu da çalışma süresini ciddi biçimde etkileyebiliyor. Sorgu beklenenden yavaş ilerlediğinde, mevcut ilerleme bilgisine dayanarak sorguyu yeniden planlama özelliğine ihtiyaç duyuluyor. Ancak Postgres streaming query desteği sunduğu için, yürütmenin ortasında planı değiştirmek önemli altyapı değişiklikleri gerektiriyor.
• Sorgu görselleştirme aracı olarak explain.dalibo.com ve www.pgexplain.dev kullandığını söyleyen bir kullanıcı var. Her iki araç da benzer çıktılar sunuyor.
• Sorgu planlayıcısındaki iyileştirmelerin veritabanında önemli bir alan olduğu, ancak çoğunlukla istenildiği gibi çalışmadığında fark edildiği yönünde bir görüş var. Son Postgres sürümlerindeki JIT (Just-In-Time) derleyicisinin kullanım anındaki heuristiklerinin yeterince sağlam görünmediği, küçük veri setlerinde yavaşlamaya neden olabildiği ve bu yüzden JIT'i devre dışı bırakmanın daha iyi olduğuna dair bir deneyim paylaşılıyor.
• Değişikliklerin gerçek sorgularda ne kadar sık etkili olduğu, özellikle de "mümkün olduğunda DISTINCT yerine Limit kullan" değişikliğinin pratikte gerçekten devreye girip girmediği merak ediliyor. Postgres geliştiricilerinin bu konuda bilgi sahibi olup olmadığı soruluyor.
• Uygulama testi için bir "strict mode" olmasının iyi olacağı yönünde bir görüş var. Bu modda, sorguyu iyileştirebilecek bir indeks yoksa hata döndürülür ve CREATE INDICES FOR <sql> komutuyla gerekli indeksler oluşturulabilir. Geliştirme ve etkileşimli kullanım için otomatik indeks oluşturma modu da öneriliyor.
• Bir kullanıcının arkadaşının KOBİ'ler için Microsoft DBA olarak çalıştığı ve Postgres ile ciddi işlerin yapılamayacağını iddia ettiği aktarılıyor. Postgres'te sorgu planlayıcısı olmadığına şaşırdığı söyleniyor, ancak bu yanlış bilgi. MSSQL'in Postgres'ten daha büyük ölçekli işleri kaldırabildiği iddiasının ne kadar güvenilir olduğu soruluyor.
• Postgres'in neden hint'leri uygulamadığı sorgulanıyor.
• Citus Data'nın duyurduğu özelliğin neden postgresql.org yerine başka bir yerde yayımlandığı, bunun ücretli bir özellik mi yoksa açık kaynaklı bir eklenti mi olduğu soruluyor.
• Postgres'in IS NOT DISTINCT FROM sorgularını hızlandırmak için indeksi ne zaman kullanabildiği soruluyor.
• Bir yorum şikayet edilerek flagged durumuna alınmış.