Kursor adalah pilihan yang masuk akal untuk paging di aplikasi intranet yang lebih kecil yang bekerja dengan kumpulan data besar, tetapi Anda harus siap untuk membuangnya setelah batas waktu. Pengguna suka berkeliaran, pergi makan siang, pergi berlibur selama dua minggu, dll, dan membiarkan aplikasi mereka berjalan. Jika ini adalah aplikasi berbasis web, bahkan ada pertanyaan tentang apa itu "berjalan" dan bagaimana cara mengetahui apakah pengguna masih ada.
Mereka tidak cocok untuk aplikasi skala besar dengan jumlah klien tinggi dan klien yang datang dan pergi hampir secara acak seperti di aplikasi berbasis web atau API web. Saya tidak akan merekomendasikan menggunakan kursor di aplikasi Anda kecuali Anda memiliki jumlah klien yang cukup kecil dan tingkat permintaan yang sangat tinggi ... dalam hal ini mengirim kumpulan kecil baris akan sangat tidak efisien dan Anda harus berpikir untuk mengizinkan rentang-permintaan dll.
Kursor memiliki beberapa biaya. Jika kursor tidak WITH HOLD Anda harus menjaga transaksi tetap terbuka. Transaksi terbuka dapat mencegah autovacuum melakukan tugasnya dengan benar, menyebabkan tabel mengasapi dan masalah lainnya. Jika kursor dinyatakan WITH HOLD dan transaksi tidak diadakan terbuka Anda harus membayar biaya mewujudkan dan menyimpan set hasil yang berpotensi besar - setidaknya, saya pikir itulah cara kerja kursor terus. Alternatifnya sama buruknya, menjaga transaksi tetap terbuka hingga kursor dihancurkan dan mencegah baris dibersihkan.
Selain itu, jika Anda menggunakan kursor, Anda tidak dapat mengembalikan koneksi ke kumpulan koneksi. Anda memerlukan satu koneksi per klien. Itu berarti lebih banyak sumber daya backend digunakan hanya dengan mempertahankan status sesi, dan menetapkan batas atas yang sangat nyata pada jumlah klien yang dapat Anda tangani dengan pendekatan berbasis kursor.
Ada juga kerumitan dan overhead dalam mengelola pengaturan berbasis kursor stateful dibandingkan dengan pendekatan penyatuan koneksi stateless dengan batas dan offset. Anda harus membuat aplikasi Anda kedaluwarsa kursor setelah batas waktu atau Anda menghadapi kemungkinan penggunaan sumber daya yang tidak terbatas di server, dan Anda perlu melacak koneksi mana yang memiliki kursor mana yang hasilnya ditetapkan untuk pengguna mana....
Secara umum, meskipun faktanya bisa sangat tidak efisien, LIMIT dan OFFSET bisa menjadi solusi yang lebih baik. Seringkali lebih baik mencari kunci utama daripada menggunakan OFFSET , meskipun.
Omong-omong, Anda sedang melihat dokumentasi untuk kursor di PL/pgSQL. Anda menginginkan kursor tingkat SQL normal untuk pekerjaan ini.
Apakah kursor mengharuskan koneksi database dibiarkan terbuka?
Ya.
Apakah kursor berjalan di dalam transaksi, mengunci sumber daya hingga "ditutup"?
Ya, kecuali mereka WITH HOLD , dalam hal ini mereka menggunakan sumber daya database lainnya.
Apakah ada "gotcha" lain yang tidak saya ketahui?
Ya, seperti yang dijelaskan di atas.
