Apa yang baru di Postgres-XL 9.6

Selama beberapa bulan terakhir, kami di 2ndQuadrant telah berupaya menggabungkan PostgreSQL 9.6 ke dalam Postgres-XL, yang ternyata cukup menantang karena berbagai alasan, dan membutuhkan waktu lebih lama dari yang direncanakan karena beberapa perubahan hulu yang invasif. Jika Anda tertarik, lihat repositori resmi di sini (lihat cabang “master” untuk saat ini).

Masih ada sedikit pekerjaan yang harus dilakukan – menggabungkan beberapa bit yang tersisa dari upstream, memperbaiki bug yang diketahui dan kegagalan regresi, pengujian, dll. Jika Anda mempertimbangkan untuk berkontribusi pada Postgres-XL, ini adalah peluang yang ideal (kirim saya email dan saya akan membantu Anda dengan langkah pertama).

Namun secara keseluruhan, Postgres-XL 9.6 jelas merupakan langkah maju yang besar di sejumlah bidang penting.

Fitur baru di Postgres-XL 9.6

Jadi, fitur baru apa yang diperoleh Postgres-XL dari penggabungan PostgreSQL 9.6? Saya hanya dapat mengarahkan Anda ke catatan rilis upstream – sebagian besar peningkatan langsung berlaku untuk XL 9.6, dengan pengecualian yang terkait dengan fitur yang tidak didukung di XL.

Peningkatan utama yang terlihat oleh pengguna di PostgreSQL 9.6 jelas merupakan kueri paralel, dan itu juga berlaku untuk Postgres-XL 9.6.

Paralelisme intra-simpul

Sebelum PostgreSQL 9.6, Postgres-XL adalah salah satu cara untuk mendapatkan kueri paralel (dengan menempatkan beberapa node Postgres-XL pada mesin yang sama). Sejak PostgreSQL 9.6 itu tidak lagi diperlukan, tetapi itu juga berarti Postgres-XL memperoleh kemampuan paralelisme intra-node.

Sebagai perbandingan, inilah yang Postgres-XL 9.5 memungkinkan Anda lakukan – mendistribusikan kueri ke beberapa node data, tetapi setiap node data masih tunduk pada batas “satu backend per kueri”, sama seperti PostgreSQL biasa.

Berkat fitur kueri paralel PostgreSQL 9.6, Postgres-XL 9.6 sekarang dapat melakukan ini:

Artinya, setiap node data sekarang dapat menjalankan bagian dari kuerinya secara paralel, menggunakan infrastruktur kueri paralel hulu. Itu bagus dan membuat Postgres-XL jauh lebih kuat dalam hal beban kerja analitis.

Memelihara garpu

Saya menyebutkan penggabungan ini ternyata lebih menantang daripada yang kami perkirakan sebelumnya, karena beberapa alasan.

Pertama, mempertahankan fork secara umum itu sulit, terutama ketika proyek upstream bergerak secepat PostgreSQL. Anda perlu mengembangkan fitur khusus untuk garpu Anda, itulah sebabnya garpu ada sejak awal. Tetapi Anda juga ingin mengikuti hulu, jika tidak, Anda akan tertinggal jauh di belakang. Itulah sebabnya beberapa fork yang ada masih macet di PostgreSQL 8.x, kehilangan semua hal baik yang dilakukan sejak saat itu.

Kedua, penggabungan dilakukan dalam satu gumpalan besar, sama seperti semua yang sebelumnya (9.5, 9.2, …). Artinya, semua komit upstream digabungkan dalam satu perintah git merge. Itu dijamin akan menyebabkan banyak konflik penggabungan, sampai-sampai kode tidak bisa dikompilasi, belum lagi menjalankan tes regresi atau semacamnya.

Jadi batch pertama perbaikan adalah tentang membuatnya menjadi keadaan yang dapat dikompilasi, batch berikutnya adalah tentang membuatnya benar-benar berjalan tanpa segfault langsung, dan akhirnya perbaikan "reguler" dimulai (jalankan tes regresi, perbaiki masalah, bilas dan ulangi) .

Kompleksitas ini melekat pada pemeliharaan fork (dan alasan mengapa Anda mungkin harus mempertimbangkan kembali untuk memulai fork lain, dan sebagai gantinya berkontribusi langsung baik ke Postgres dan/atau Postgres-XL).

Tetapi ada cara untuk mengurangi dampak secara signifikan – misalnya kami berencana untuk melakukan penggabungan berikutnya (dengan PostgreSQL 10) dalam potongan yang lebih kecil. Itu akan meminimalkan tingkat konflik gabungan dan memungkinkan kami menyelesaikan kegagalan lebih cepat.

Mendekati PostgreSQL

Yang cukup menarik, adopsi paralelisme dari hulu juga memungkinkan kami untuk menyingkirkan banyak kode dari basis kode XL – contoh utama dari ini adalah kode agregat paralel, yang dengan mudah menggantikan kode khusus XL.

Contoh lain dari perubahan upstream yang secara signifikan mempengaruhi kode XL adalah "pathification" perencana atas, yang didorong di akhir siklus pengembangan 9.6. Ini ternyata menjadi perubahan yang sangat invasif (sebenarnya sejumlah bug terbuka kemungkinan terkait dengannya), tetapi pada akhirnya memungkinkan kami untuk menyederhanakan kode perencanaan (pada dasarnya membangun jalur yang tepat alih-alih mengubah rencana yang dihasilkan).

Ketika saya mengatakan penggabungan memungkinkan kami untuk menyederhanakan kode XL dan membuatnya lebih dekat ke PostgreSQL, apa yang saya maksud dengan itu? Cara paling sederhana untuk mengukur perubahan adalah dengan melakukan “git diff –stat” terhadap cabang upstream yang cocok, dan membandingkan angka-angkanya. Untuk cabang 9.5 dan 9.6, hasilnya seperti ini:

Jelas, penggabungan 9,6 secara signifikan mengurangi delta terhadap hulu (total ~14%). Dari mana perbedaan ini berasal?

Pertama, sebagian dari pengurangan itu disebabkan oleh penyederhanaan kode asli. Contoh utama dari ini adalah agregat paralel, yang merupakan pengganti 1:1 dari implementasi Postgres-XL asli. Jadi kami baru saja mencabutnya dan menggunakan implementasi upstream sebagai gantinya. Kami berharap dapat menemukan lebih banyak tempat seperti itu di masa mendatang, dan menggunakan implementasi hulu daripada mempertahankan milik kami sendiri.

Kedua, banyak pengurangan berasal dari menghapus kode mati. Tidak hanya kami telah mengurangi beberapa bit kode yang mati/tidak dapat dijangkau, kami juga menemukan beberapa file sumber yang bahkan tidak dikompilasi, dan seterusnya.

Apa selanjutnya?

Pada titik ini kami telah menggabungkan perubahan hingga b5bce6c1, yang merupakan tempat di mana PostgreSQL 9.6 berpisah dari master. Jadi untuk mengejar PostgreSQL 9.6.2 kita perlu menggabungkan perubahan yang tersisa di cabang 9.6. Mengingat seharusnya hanya ada perbaikan bug, itu seharusnya (semoga) pekerjaan yang cukup sederhana dibandingkan dengan penggabungan penuh.

Tentu saja, akan ada bug. Faktanya, masih ada beberapa tes regresi yang gagal pada saat ini. Itu perlu diperbaiki sebelum membuat rilis resmi XL 9.6. Dan kami perlu melakukan lebih banyak pengujian, jadi jika Anda tertarik untuk membantu Postgres-XL, ini akan sangat bermanfaat.

Satu gangguan yang terus kami dengar adalah paket, atau kekurangannya. Anda mungkin telah memperhatikan bahwa paket terakhir yang tersedia cukup lama, dan hanya ada .rpm, tidak ada yang lain. Kami berencana untuk mengatasi hal ini dan mulai menawarkan paket terbaru dalam berbagai rasa (mis. .rpm dan .deb).

Kami juga berencana untuk membuat beberapa perubahan pada bagaimana proses pembangunan diatur, untuk lebih mudah berkontribusi dan berpartisipasi dalam proses pembangunan. Itu benar-benar topik terpisah yang tidak terkait dengan cabang 9.6, jadi saya akan memposting detail lebih lanjut tentang itu dalam beberapa hari.