PG12: Patch Lusin dari Postgres Professional

Sangat menyenangkan melihat nama-nama yang sudah dikenal pada daftar Ucapan Terima Kasih dari rilis resmi PostgreSQL 12. Kami memutuskan untuk menyatukan inovasi dan beberapa perbaikan bug yang dilakukan oleh pengembang kami.

1. Dukungan JSONPath

(Dalam Catatan Rilis, ini terdengar seperti Tambahkan dukungan untuk bahasa jalur SQL / JSON (Nikita Glukhov, Teodor Sigaev, Alexander Korotkov, Oleg Bartunov, Liudmila Mantrova)

Tambalan ini sendiri, fitur JSONPath, dan riwayat masalah dibahas secara rinci dalam artikel terpisah di sini di hub JSONPath adalah pencapaian utama Postgres Professional dan salah satu inovasi utama PostgreSQL 12 secara umum.

Pada tahun 2014, A. Korotkov, O. Bartunov, dan F. Sigaev mengembangkan ekstensi jsquery , yang dimasukkan sebagai hasil dalam Postgres Pro Standard 9.5 (dan kemudian versi Standard and Enterprise). Ini menyediakan fitur tambahan yang sangat luas untuk bekerja dengan json (b).

Ketika standar SQL: 2016 muncul, ternyata semantiknya tidak begitu berbeda dengan kita dalam ekstensi jsquery. Ada kemungkinan bahwa penulis standar bahkan melirik jsquery, menciptakan JSONPath. Tim kami harus menerapkan sedikit berbeda dari apa yang sudah kami miliki dan, tentu saja, banyak hal baru juga.

Meskipun tambalan khusus dengan fungsi belum dilakukan, tambalan JSONPath sudah memiliki fungsi utama untuk bekerja dengan JSON (B), misalnya:

jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 2)')  3, 4, 5 jsonb_path_query('{"a": [1,2,3,4,5]}', '$.a[*] ? (@ > 5)')  0  

Selain itu, beberapa fungsi yang sudah bekerja dengan JSON sebelumnya dioptimalkan . Ini berhasil dilakukan oleh Nikita Glukhov.

Misalnya, operator #>> , yang sesuai dengan fungsi jsonb_each_text() dan jsonb_array_elements_text() , digunakan untuk dengan cepat mengkonversi JsonbValue ke teks, tetapi bekerja lambat dengan tipe lain. Sekarang semuanya bekerja dengan cepat.

2. Dukungan untuk pencarian cepat tetangga terdekat dalam indeks SP-GiST (KNN)

(Tambahkan dukungan untuk pencarian tetangga terdekat (KNN) indeks SP-GiST. Nikita Glukhov, Alexander Korotkov, Vlad Sterzhanov)

Nikita Glukhov dan Alexander Korotkov dari perusahaan kami melanjutkan pekerjaan yang dimulai oleh Vlad Sterzhanov dari Minsk (alias Quadrocube). Postgres adalah DBMS pertama yang mencari tetangga terdekatnya - sebelumnya Oracle dan MS, dan dengan cara yang lebih langsung dan nyaman - dan ini adalah kelebihan dari Oleg Bartunov dan timnya. Ide pencarian ini adalah dalam algoritma traversal pohon asli, yang dalam banyak kasus memberikan keuntungan besar. Pencarian tetangga terdekat banyak digunakan di mana, tetapi dalam GIS itu sangat umum.

Vlad membuat patch pencarian KNN untuk bekerja dengan indeks spasial SP-GiST untuk quad-tree, ketika pesawat dibagi menjadi kotak dengan ukuran tetap, dan untuk KD-tree, yaitu, pohon k-dimensional.

Alexander Korotkov, mentor GSoC Vlad (Google Summer of Code), melanjutkan pengembangan dengan seorang rekan dari Postgres Professional Nikita Glukhov. Fungsionalitas diperkaya dengan serius: caching data internal ditingkatkan ketika melintasi pohon, kelas operator untuk lingkaran dan poligon dengan pemesanan menurut jarak ditambahkan.

Untuk menggunakan algoritma pencarian tetangga terdekat, cukup tulis ORDER BY [, ] , dan kemudian optimizer akan secara otomatis menghubungkan algoritma ini. Sebagai contoh

 SELECT * FROM polygons ORDER BY poly <-> point '(0,0)'; 

Patch oleh Nikita Glukhov dapat dilihat di github .

3. Optimalisasi kunci untuk mempercepat penyisipan ke indeks B-Tree

(Dalam Catatan Rilis, ini adalah Meningkatkan kecepatan penyisipan indeks btree dengan mengurangi overhead penguncian. Alexander Korotkov)

Alexander Korotkov, kepala arsitek sistem di Postgres Professional, berhasil menghasilkan algoritma penguncian yang lebih masuk akal ketika dimasukkan ke dalam indeks B-tree. Keuntungan setelah menerapkan tambalan ini terlihat dalam kasus di mana penyisipan terjadi lebih atau kurang "berturut-turut". Pengukuran pada server 72-core menunjukkan bahwa dalam hal ini keuntungannya mencapai 50%. Dengan penyisipan kacau, keuntungan tidak begitu terlihat.

4. WAL Ekonomis

(Kurangi penulisan WAL overhead pembuatan indeks GiST, GIN, dan SP-GiST. Anastasia Lubennikova, Andrey V. Lepikhov)

Rangkaian tambalan ini mengurangi lalu lintas WAL yang dihasilkan saat membuat indeks GiST, GIN, dan SP-GiST. Sekarang Anda dapat login halaman indeks tersebut hanya sekali - pada akhirnya, ketika indeks sudah dibangun. Dan jika terjadi kesalahan ketika membangun indeks entri dalam WAL, upaya yang gagal tidak akan muncul sama sekali. Sebelumnya, ini hanya mungkin saat membuat B-tree dan RUM. Tambalan menggunakan mekanisme WAL umum .

Script xlog untuk memeriksa ukuran xlog . Pengujian pada database IMDB (format JSON), di mana 4M + catatan menempati 4GB, menunjukkan:

 CREATE INDEX ON imdb USING gin(jb jsonb_path_ops); 

cara lama dijalankan 205 detik, WAL 3,2 GB, dan algoritma baru memberi 133 detik, dan WAL 0,4 GB.

5. Optimalisasi pemindaian hanya indeks dalam banyak kolom.

(Izinkan pemindaian hanya indeks menjadi lebih efisien pada indeks dengan banyak kolom. Konstantin Knizhnik)

Ketika menganalisis operasi database dari salah satu klien perusahaan kami, ditemukan bahwa permintaan yang sama dieksekusi dalam beberapa kasus lebih lama sebesar 25% dengan pemindaian hanya indeks daripada dengan pemindaian indeks (enable_indexonlyscan = off).
Ini terjadi ketika SELECT dilakukan pada banyak bidang, yang sebagian besar dari jenis bytea , dan offset mereka tidak di-cache, karena bidang tersebut tidak memiliki offset tetap (lihat juga laporan oleh Nikolai Shaplov “What's Inside It” ). Untuk membongkar atribut k-th, Anda harus membongkar k-1 sebelumnya. Membongkar catatan dengan satu atribut memerlukan waktu O (N * N), di mana N adalah jumlah bidang. 25% ini sudah terjadi di 10 bidang.

Konstantin Knizhnik menggunakan algoritma yang digunakan ketika bekerja dengan pinggul: ketika mengakses atribut k-th, k-1 sebelumnya diambil dan diingat, waktu tumbuh secara linier dengan jumlah bidang. Setelah menerapkan tambalan, runtime dengan pemindaian indeks dan hanya pemindaian indeks praktis sama.

6. Kontrol dumping segmen WAL ke disk

(Tambahkan acara tunggu untuk fsync dari segmen WAL. Konstantin Knizhnik)

Kernel PostgreSQL memonitor penulisan ke WAL, tetapi tidak memantau pembilasan segmen WAL dari memori ke disk, mis. fsync . K. Knizhnik membuat tambalan yang menciptakan jenis acara baru, sekarang disebut WALSync (nama internal variabelnya adalah WAIT_EVENT_WAL_SYNC). Anda dapat melihatnya di label acara PG dengan penjelasan "Menunggu file WAL dibuang ke penyimpanan yang dapat diandalkan". Masalah ini dibahas pada milis peretas .

Berapa lama waktu reset biasanya tidak diketahui: PostgreSQL standar tidak tahu bagaimana menggabungkan statistik tersebut. Tetapi ada ekstensi pg_wait_sampling yang ditulis dalam Postgres Professional. Itu dapat berbicara tentang acara apa yang dihabiskan Postgres. Sekarang acara telah ditambahkan, Anda dapat mengikuti fsync .

7. Dukungan untuk bahasa baru dalam kamus stemmer

(Perbarui kamus stemmer Snowball dengan dukungan untuk bahasa baru. Arthur Zakirov)

Karena konferensi Postgres diadakan di Nepal, jauh lebih alami untuk menambahkan bahasa Nepal ke dalam basis data! Ini dilakukan. Berkat upaya Arthur Zakirov, sekarang Anda dapat menggunakan kamus stemming Nepal di Snowball .

8. Fungsi to_timestamp () / to_date () menjadi lebih toleran terhadap data

(Sesuaikan to_timestamp () / to_date () berfungsi untuk lebih memaafkan ketidakcocokan templat, Artur Zakirov, Alexander Korotkov, Liudmila Mantrova)

Fungsi to_timestamp() tidak berfungsi jika string format diproses dengan spasi tambahan. Diskusi bug di to_timestamp() menghasilkan diskusi panjang tentang perilaku fungsi to_timestamp() dan, pada saat yang sama, to_date() dianggap benar. Untuk keuntungan semua orang, kedua fungsi menjadi lebih toleran terhadap ruang ekstra di baris format dan jalur input.

9. Log dapat diputar melalui pg_ctl

(Izinkan kontrol rotasi file log melalui pg_ctl. Kyotaro Horiguchi, Alexander Kuzmenkov, Alexander Korotkov)

Dengan kata lain, utilitas pg_ctl telah memperoleh opsi baru:

 pg_ctl logrotate [-D _] [-s] 

Ketika perintah ini dijalankan, server akan beralih ke file log baru atau membuka kembali yang sudah ada, tergantung pada konfigurasi logging . Ini mungkin diperlukan dalam situasi darurat, terutama ketika file log yang besar dan cepat tumbuh perlu, misalnya, ditransfer untuk diagnosis.

10. Kemampuan untuk membuat jenis tabel baru (penyimpanan Pluggable)

(Tambahkan perintah CREATE ACCESS METHOD untuk membuat jenis tabel baru. Andres Freund, Haribabu Kommi, Álvaro Herrera, Alexander Korotkov, Dmitry Dolgov)

Tambalan penting ini merupakan bagian penting dari infrastruktur API Penyimpanan Pluggable, karenanya komposisi internasional pengembang tempel. Perintah CREATE ACCESS METHOD telah berjalan di Postgres sejak versi 9.6. Tetapi sampai tanggal 12, Anda hanya bisa membuat metode akses indeks. Berikut adalah dokumentasi untuk versi ke-11 :

 CREATE ACCESS METHOD  TYPE __ HANDLER _ < ... > __       .      INDEX. 

Dan dalam dokumentasi untuk tanggal 12 sudah dibaca : saat ini hanya TABLE dan INDEX yang didukung. Kebetulan, dalam perintah CREATE ACCESS METHOD ke-11 disediakan oleh ekstensi Postgres Pro, dan pada tanggal 12 sudah PostgreSQL.

Eksekusi operasi tergantung pada jenis metode akses; jika ini adalah tipe TABLE, maka table_am_handler akan table_am_handler , dan jika ini adalah tipe INDEX, maka index_am_handler (sebelumnya: untuk metode akses tipe INDEX, ia harus index_am_handler ). Seluruh bab telah muncul dalam dokumentasi tentang metode tabel.

Saat membuat tabel, sekarang Anda dapat menentukan tipenya:

 CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] _ ( [ < ... > [ USING  ] 

metode ini bertipe TABEL - ini adalah referensi untuk Penyimpanan Pluggable. Sekarang heap secara default, dan sebelum yang lain, pada kenyataannya, itu tidak. Tentang kelas operator di sini

default_table_access_method (string)

Parameter ini menetapkan metode akses tabel default yang akan digunakan saat membuat tabel atau tampilan terwujud jika metode akses tidak ditentukan secara spesifik dalam perintah CREATE, atau ketika menjalankan perintah SELECT ... INTO, di mana metode akses tidak dapat ditetapkan secara eksplisit. Nilai defaultnya adalah heap . Diskusi besar di peretas membantu mengeluarkan detailnya.

Hingga saat ini, kami berbicara tentang inovasi. Tetapi perbaikan bug juga menggerogoti sumber daya waktu para programmer. Yang utama adalah:

11. Bug: kesalahan di salah satu struktur

Kutipan tambahan_all_identifiers di _dumpOptions. Arthur Zakirov)

Secara umum, tidak ada yang istimewa, kesalahan ditemukan di salah satu struktur yang menggunakan pg_dump - itu dilewatkan oleh kompiler. Tapi Bruce Momjyan sendiri memuji penemuan itu.

Masalah lain dengan DumpOptions dapat ditemukan di sini .

12. Bug dalam replikasi:

(xlogreader: jangan membaca blok file dua kali. Arthur Zakirov)

Karyawan lain dari perusahaan kami, pengembang pg_probackup , Grigory Smolkin, menemukan bahwa salah satu utilitas kami melambat ketika xlogreader membaca arsip zlib. Ternyata kadang-kadang dia membaca blok file WAL dua kali.

Jika arsip dibaca tidak konsisten, maka kinerjanya buruk. Pembacaan berulang blok selalu tidak konsisten, karena Anda harus kembali ke posisi yang dilewati dengan memanggil fungsi gzseek() . Sekarang membaca ulang yang tidak perlu tidak terjadi.

PS Saya tidak akan menyembunyikan: selusin tambalan (tepatnya serangkaian tambalan) tidak hanya kebetulan kebetulan dengan nomor versi Postgres. Daftarnya bisa saja di bawah lusinan atau di atas lusinan. Saya pikir itu akan menjadi lebih indah, dan kecantikan adalah sebagian dari mesin pemrograman, belum lagi area lain dari aktivitas manusia.