Sebenarnya, istilah "prosedur tersimpan" menunjuk ke prosedur SQL di Postgres, diperkenalkan dengan Postgres 11. Terkait:
Ada juga fungsi , melakukan hampir tetapi tidak persis sama, dan itu sudah ada sejak awal.
Fungsi - fungsi dengan LANGUAGE sqlpada dasarnya hanyalah file batch dengan perintah SQL biasa dalam fungsi wrapper (dan karena itu atomik, selalu dijalankan dalam satu transaksi tunggal ) menerima parameter. Semua pernyataan dalam fungsi SQL direncanakan sekaligus , yang agak berbeda dari mengeksekusi satu pernyataan setelah yang lain dan dapat mempengaruhi urutan pengambilan kunci.
Untuk yang lainnya, bahasa yang paling matang adalah PL / pgSQL ( LANGUAGE plpgsql). Ini bekerja dengan baik dan telah ditingkatkan dengan setiap rilis selama dekade terakhir, tetapi berfungsi terbaik sebagai lem untuk perintah SQL. Ini tidak dimaksudkan untuk perhitungan berat (selain dengan perintah SQL).
Fungsi PL / pgSQL menjalankan query seperti pernyataan yang disiapkan . Menggunakan kembali rencana permintaan yang di-cache memotong beberapa overhead perencanaan dan membuatnya sedikit lebih cepat dari pernyataan SQL yang setara, yang mungkin merupakan efek yang terlihat tergantung pada keadaan. Mungkin juga memiliki efek samping seperti dalam pertanyaan terkait ini:
Ini membawa kelebihan dan kekurangan dari pernyataan yang disiapkan - sebagaimana dibahas dalam manual . Untuk query pada tabel dengan distribusi data yang tidak teratur dan bervariasi parameter SQL dinamis dengan EXECUTEdapat melakukan lebih baik ketika keuntungan dari rencana eksekusi dioptimalkan untuk parameter yang diberikan (s) melebihi biaya re-perencanaan.
Karena Postgres 9.2 rencana eksekusi umum masih di-cache untuk sesi ini tetapi, mengutip manual :
Ini terjadi segera untuk pernyataan yang disiapkan tanpa parameter; jika tidak, itu terjadi hanya setelah lima atau lebih eksekusi menghasilkan rencana yang perkiraan biaya rata-rata (termasuk biaya overhead perencanaan) lebih mahal daripada perkiraan biaya rencana umum.
Kami mendapatkan yang terbaik dari kedua dunia sebagian besar waktu (kurang beberapa overhead tambahan) tanpa menggunakan (ab) EXECUTE. Detail dalam Apa yang baru di PostgreSQL 9.2 dari PostgreSQL Wiki .
Postgres 12 memperkenalkan variabel serverplan_cache_mode tambahan untuk memaksa paket generik atau kustom. Untuk kasus khusus, gunakan dengan hati-hati.
Anda dapat menang besar dengan fungsi-fungsi sisi server yang mencegah bolak- balik tambahan ke server database dari aplikasi Anda. Mintalah server mengeksekusi sebanyak mungkin sekaligus dan hanya mengembalikan hasil yang terdefinisi dengan baik.
Hindari bersarang fungsi kompleks, terutama fungsi tabel ( RETURNING SETOF recordatau TABLE (...)). Fungsinya adalah kotak hitam yang menyamar sebagai penghalang optimasi perencana kueri. Mereka dioptimalkan secara terpisah, bukan dalam konteks permintaan luar, yang membuat perencanaan lebih sederhana, tetapi dapat menghasilkan rencana yang kurang sempurna. Juga, biaya dan hasil ukuran fungsi tidak dapat diprediksi dengan andal.
The pengecualian untuk aturan ini adalah fungsi SQL sederhana ( LANGUAGE sql), yang dapat "inline" - jika beberapa prasyarat terpenuhi . Baca selengkapnya tentang cara kerja perencana kueri dalam presentasi ini oleh Neil Conway (hal lanjut).
Dalam PostgreSQL, fungsi selalu berjalan secara otomatis dalam satu transaksi . Semua itu berhasil atau tidak sama sekali. Jika pengecualian terjadi, semuanya dibatalkan. Tetapi ada penanganan kesalahan ...
Itu juga sebabnya fungsi tidak persis "prosedur tersimpan" (meskipun istilah itu kadang-kadang digunakan, menyesatkan). Beberapa perintah suka VACUUM, CREATE INDEX CONCURRENTLYatau CREATE DATABASEtidak bisa berjalan di dalam blok transaksi, sehingga tidak diizinkan dalam fungsi. (Baik dalam prosedur SQL, belum, pada Postgres 11. Itu mungkin ditambahkan nanti.)
Saya telah menulis ribuan fungsi plpgsql selama bertahun-tahun.