Pada bagian
pertama, kita berbicara tentang inovasi utama dan perubahan dalam PostgreSQL 11. Kali ini, kita akan membahas secara lebih rinci beberapa poin dalam format pertanyaan / jawaban yang diangkat oleh meetup.
Apa cara terbaik untuk mentransfer array data besar sebagai satu set parameter input untuk prosedur tersimpan di PL / pgSQL?
Cara yang paling mudah adalah membuat tabel sementara, membuat salinan data di sana, dan kemudian menggunakannya dalam prosedur.
Mesin eksternal (zheap) dan pengembangan di memori PostgreSQL
Tidak untuk semua beban kerja, model dengan menyimpan catatan versi lama di tabel itu sendiri cocok. Di semua subd (versiionniki) lainnya, mereka disimpan dalam undo-log. Anda bisa berdebat tentang kelayakannya, tetapi intinya adalah Anda perlu menyimpan catatan lama di suatu tempat. Jika mereka memiliki umur yang pendek dan seseorang jarang mengatasinya, maka menyimpannya di meja itu sendiri berbahaya. Mesin zheap eksternal PostgreSQL adalah upaya EnterpriseDB untuk membuat mesin tabel untuk PostgreSQL dengan batalkan log. Berhasil, meskipun masih ada sesuatu untuk diperbaiki.
Siapa yang bekerja dengan Ms. SQL dalam mode Level Isolasi SNAPSHOT, tahu bahwa ia memiliki tempdb, di mana ia menempatkan versi lama, dan dilengkapi dengan vakum yang cukup dewasa untuk membersihkan tempdb. Di sisi lain, komunitas meminta untuk membuat tabel dalam memori di PostgreSQL. Ini dapat dilakukan dengan cukup mudah: tmpfs, dan hanya itu. Di PostgreSQL Pro bahkan merilis versi pilot pertama, Anda dapat mencoba.
Apa yang PostgreSQL tidak pernah miliki adalah mesin plug-in. Ada indeks pluggable yang menggunakan WAL umum. PostgreSQL memiliki banyak plug-in dan sedikit untuk diganti dengan cepat. Misalnya, pelaksana tidak dinonaktifkan, tetapi Anda sudah dapat menggunakan simpul khusus di dalamnya yang Anda program sendiri. Pengoptimal dalam PostgreSQL sepenuhnya dapat dicolokkan. Anda dapat menulis sendiri dan menggunakan PostgreSQL sebagai juru bahasa dari pertanyaan Anda. SQL parser tidak dapat dihubungkan.
Mesin ingin terhubung dalam tiga arah:
- mesin dengan batalkan log
- dalam memori
- penyimpanan kolom untuk kueri OLAP
Postgres Pro sedang dalam pembicaraan dengan EnterpriseDB tentang cara membuat API untuk menghubungkan semua ini.
Tentang kunci asing
Kunci asing di dalam PostgreSQL diimplementasikan oleh pemicu. Anda dapat menulis pemicu Anda yang akan menerapkan segala jenis fungsi. Semua pembatasan yang mungkin harus dilakukan dalam pelatuk. Logika dalam pemicu tidak terlalu diperlukan untuk disimpan, tetapi periksa semuanya - itu perlu.
Apakah Postgres Pro berencana untuk melakukan SaaS atau PaaS?
Postgres Pro berencana untuk membuat PostgreSQL lebih dioptimalkan untuk cloud, khususnya, untuk menerapkan perubahan dinamis untuk membagikan buffer, untuk mengurangi jumlah parameter yang memerlukan restart PostgreSQL. Mereka tidak akan membangun awan sendiri.
Bagaimana cara mengatur drive agar pengindeksan paralel berfungsi lebih cepat? Mana yang lebih baik, banyak HDD atau satu SSD?
Lebih baik beberapa SSD. Semakin banyak opsi paralelisasi yang disediakan perangkat keras, semakin baik. Jika Anda memiliki satu disk, tidak cukup memori dan satu prosesor, maka paralelisasi tidak akan membantu Anda. Tetapi SSD memiliki kekhasan: mereka mulai melambat jika lebih dari 80% volume ditempati. Karena itu, jangan lupa untuk menyesuaikan trim, jika tidak, batas 80% akan datang di suatu tempat sekitar 50%.
Manajemen kamus dan menambahkan kata-kata dalam pencarian teks lengkap
Jika Anda menggunakan mantra atau bola salju, maka cukup ganti kamus kata-berhenti. Masalahnya adalah jika Anda menambahkan kata berhenti, maka tidak ada gunanya mengindeks. Ini bisa dilakukan secara perlahan. Kata berhenti akan dikeluarkan dari permintaan dan tidak pernah dicari. Dan jika Anda menghapus kata berhenti, maka tidak ada dalam koleksi itu tidak ada dan Anda perlu mengindeksnya kembali. Masalahnya bukan di kamus, tetapi pada kenyataan bahwa Anda telah menggunakannya dan menyimpan pengetahuan Anda.
Selain itu, dalam banyak kasus, Anda dapat menggunakan fungsi ts_rewrite yang tidak banyak diketahui, yang memungkinkan Anda mengganti sebagian permintaan dengan permintaan lain. Misalnya, ketika kapal selam Kursk tenggelam, semua orang bergegas mencari informasi tentang itu. Fedor Sigaev pada waktu itu bekerja di rambler, dan atas permintaan "Kursk" informasi tentang kota diberikan. Mereka segera melakukan substitusi: dengan kata ini, berikan informasi tentang kapal selam. Tetapi kemudian pengguna mulai mengutuk, yang tertarik pada desa itu sendiri. Saya tidak tahu apakah mereka sadar atau tidak, tetapi itu perlu untuk memperkenalkan "kota Kursk". Pergantian demikian memungkinkan ts_rewrite dibuat. Selain itu, fungsi ini dapat digunakan untuk transisi yang lancar selama periode perubahan kamus.
Tentu saja, mengubah pengurai dan kamus adalah tugas yang rumit. Bahasa dengan huruf yang berbeda, seperti Rusia dan Inggris, rukun. Jauh lebih buruk sekarang adalah, katakanlah, teks Prancis-Inggris. Tidak jelas bahasa apa yang dirujuk oleh kata, yang ditulis dengan cara yang sama, tetapi dalam satu bahasa itu adalah kata berhenti, dan dalam bahasa lain tidak. Postgres Pro saat ini sedang mengerjakan kamus fine-tuning untuk menggambarkan konfigurasi yang lebih kompleks.
Meliputi indeks dan pembaruan terbaru
Ini benar-benar teman. Benar, jika setidaknya satu bidang diperbarui dalam indeks penutup, maka indeks akan berperilaku seperti biasa, semuanya akan diganti.
Ketidakmampuan untuk membuat tabel sementara saat mengeksekusi permintaan siaga
PostgreSQL tidak menyimpan pengetahuan tabel dalam direktori sistem, tetapi ada tambalan yang mentransfer pengetahuan ke direktori sistem. Oleh karena itu, dengan tambalan ini Anda dapat menggunakan tabel sementara. Tetapi kemudian muncul masalah lain: tidak ada transaksi yang ditunda. Untuk bekerja dengan tabel sementara, Anda harus menggunakan dua kali id transaksi virtual, yang hanya berlaku untuk tabel sementara, dan bukan untuk yang utama yang berasal dari panduan. Dan ketika Anda melihat angka 32-bit, mereka akan menjadi dua angka yang berbeda.
Postgres Pro juga memiliki modul pg_variables, yang juga berfungsi stand by. Ini bukan tabel sementara, tetapi fungsionalitas yang diperlukan dapat digambarkan.
Menerapkan Indeks Cluster
Postgres Pro memiliki beberapa upaya untuk mengimplementasikannya. Sekarang Anda bisa memasukkan indeks tabel cluster dan tabel akan berada dalam urutan yang sama. Menderita cara mempertahankan tabel dalam keadaan cluster. Kami mencoba pendekatan yang berbeda, tetapi selalu memasukkan ke dalam tabel seperti itu sangat mahal. Dan ini tidak menarik bagi siapa pun. Oleh karena itu, sejauh ini telah disimpulkan bahwa perlu untuk pindah ke Tabel Tabel Terorganisir.
Faktor skala autovacuum yang direkomendasikan
Biasanya merekomendasikan pengaturan 1 - 5%. Tapi ini sepenuhnya opsional. Untuk tabel kecil, di mana, meskipun ada perubahan, rata-rata, distribusi yang sama tetap, nilai yang besar dapat ditetapkan. Jika meja besar dan jarang diisi ulang, tetapi tepat, dengan perubahan distribusi yang kuat, Anda harus menciptakan sesuatu yang lain. Itu semua tergantung pada distribusi data Anda.
Petunjuk dalam pertanyaan kompleks
Di Oracle, dengan pertanyaan kompleks, Anda harus secara berkala membantu dengan petunjuk, karena pemindaian penuh tiba-tiba terjadi. Ada petunjuk di Postgres Pro, cukup moody, tetapi Anda bisa mendapatkannya. Namun, tidak ada petunjuk dalam PostgreSQL biasa, dan mereka tidak akan muncul. Jika Anda memiliki petunjuk bawaan, maka pengguna, dihadapkan dengan masalah pengoptimal, sisipkan petunjuk, tenang dan jangan melaporkan masalah. Pengembangan pengoptimal berhenti.
Omong-omong, pengoptimal PostgreSQL memiliki masalah. Ketika dia memperkirakan sampel dari tabel, bahkan untuk jumlah yang lebih atau kurang masuk akal, dia menebak dengan beberapa kesalahan. Kemudian mulai terhubung, hasilnya terhubung ke sesuatu yang lain, kesalahan terakumulasi, dan pada tingkat ketiga atau keempat PostgreSQL banyak kehilangan.
Ada pengaturan seperti itu - bergabung dengan batas keruntuhan. PostgreSQL mengurutkan BERGABUNG untuk penggunaan yang lebih efisien, tetapi batas pengurutan default adalah 8. Jika ada lebih dari 8 GABUNGAN berturut-turut, sistem tidak akan mengurutkannya dan akan ada ketergantungan pada urutan GABUNGAN dalam kueri.
Ada juga pengoptimal genetik dengan berbagai parameter. Anda dapat mengaktifkan berbagai pengaturan dalam satu sesi dan lebih atau kurang menggambarkan bagaimana permintaan harus dieksekusi. Menggunakan urutan ini, dengan bantuan tanda kurung Anda dapat mengatur penghentian beberapa operasi, pemindaian detik yang sama. Pilihan lain adalah memasukkan parameter tertentu ke dalam fungsi. Dalam beberapa hal, ini juga merupakan petunjuk. Tidak terlalu nyaman, tetapi setidaknya sesuatu.