Açıkçası, "saklı yordamlar" terimi , Postgres 11 ile tanıtılan Postgres'teki SQL prosedürlerine işaret eder.
Aynı zamanda neredeyse tamamen aynı olanı yapan fonksiyonlar da var ve bunlar başından beri oradaydı.
Fonksiyonlar ile LANGUAGE sqltemelde (her zaman içinde çalıştırmak ve dolayısıyla atom, düz SQL bir işlev ambalajında komutlarla sadece toplu dosyalarıdır tek işlem) kabul parametreler. Bir SQL işlevindeki tüm ifadeler bir kerede planlanmıştır ; bu, birbiri ardına bir ifadeyi çalıştırmaktan tamamen farklıdır ve kilitlerin alındığı sırayı etkileyebilir.
Daha fazlası için, en olgun dil PL / pgSQL ( LANGUAGE plpgsql) 'dir. İyi çalışıyor ve son on yılda her sürümde geliştirildi, ancak SQL komutları için en iyi yapıştırıcı görevi görüyor. Ağır hesaplamalar için tasarlanmamıştır (SQL komutları dışında).
PL / pgSQL işlevleri, hazırlanan ifadeler gibi sorguları çalıştırır . Önbelleğe alınmış sorgu planlarını yeniden kullanmak, bazı planlama ek yükünü keser ve eşdeğer SQL ifadelerinden biraz daha hızlı hale getirir; bu, koşullara bağlı olarak gözle görülür bir etki olabilir. Bu soruda olduğu gibi yan etkileri de olabilir:
Bu, hazırlanan açıklamaların avantajlarını ve dezavantajlarını taşır - kılavuzda tartışıldığı gibi . Düzensiz veri dağılımına ve değişken parametrelere sahip tablolardaki sorgular için, belirli parametreler için optimize edilmiş bir yürütme planından elde edilen kazanç yeniden planlama maliyetinden ağır basarsa dinamik SQL ile EXECUTEdaha iyi performans gösterebilir.
Postgres 9.2 genel uygulama planları oturum için hala önbelleğe alındığından, ancak kılavuzdan alıntı yapıldığından :
Bu, parametresiz hazırlanmış ifadeler için hemen gerçekleşir; Aksi halde, yalnızca beş veya daha fazla uygulama, tahmini maliyet ortalaması (genel gider dahil) genel plan maliyet tahmininden daha pahalı olan planları ürettikten sonra gerçekleşir.
(Ab) kullanmadan çoğu zaman her iki dünyanın da en iyisini elde ederiz (bazı ek yükler eklenir) EXECUTE. Ayrıntılar yenilikler PostgreSQL 9.2'de PostgreSQL Wiki'nin .
Postgres 12, genel veya özel planları zorlamak için ek sunucu değişkeniniplan_cache_mode sunar. Özel durumlar için dikkatli kullanın.
Sen olabilir büyük kazanmak sunucu tarafı fonksiyonları ile ek gidiş gezileri önlemek için uygulamadan veritabanı sunucusuna. Sunucunun bir kerede mümkün olduğunca çalışmasını sağlayın ve yalnızca iyi tanımlanmış bir sonuç döndürün.
Karmaşık işlevlerin, özellikle tablo işlevlerinin ( RETURNING SETOF recordveya TABLE (...)) iç içe geçmesinden kaçının . İşlevler, sorgu planlayıcısının optimizasyon engelleri olarak poz veren kara kutulardır. Planlamayı basitleştiren dış sorgu bağlamında değil, aynı zamanda mükemmel planlardan daha azına neden olabilecek şekilde ayrı ayrı optimize edilirler. Ayrıca, fonksiyonların maliyet ve sonuç büyüklüğü güvenilir bir şekilde tahmin edilemez.
İstisna Bu kuralın basit bir SQL fonksiyonları (vardır LANGUAGE sqledilebilir), "inlined" bazı ön şartlar yerine getirildiği takdirde - . Sorgu planlayıcısının bu sunumda Neil Conway (gelişmiş sayfalar) tarafından nasıl çalıştığı hakkında daha fazla bilgi edinin .
PostgreSQL'de bir fonksiyon her zaman otomatik olarak tek bir işlem içinde çalışır . Hepsi başarılı ya da hiçbir şey. Bir istisna olursa, her şey geri alınır. Ama hata işleme var ...
Fonksiyonlardır sebeplerinden biri de bu değil tam olarak "saklı yordamları" (bu terim yanlış yönlendiren, bazen kullanılır bile). Bazı komutlar gibi VACUUM, CREATE INDEX CONCURRENTLYya CREATE DATABASEda fonksiyonlar izin verilmez böylece, bir işlem bloğunun içinde çalışamaz. (Ne SQL prosedürlerinde, henüz Postgres 11'den beri. Bu daha sonra eklenebilir.)
Yıllar boyunca binlerce plpgsql işlevi yazdım.