Sebuah Ruby gem baru bernama pg_hash_func menjanjikan untuk mempercepat query hash partition PostgreSQL hingga 20 kali lipat, namun komunitas developer mempertanyakan apakah klaim performa tersebut terbukti dalam skenario dunia nyata. Gem ini bertujuan untuk melewati overhead catalog lookup PostgreSQL dengan menghitung lokasi partition secara langsung dalam kode aplikasi.
Kurangnya Bukti Performa Dunia Nyata
Kekhawatiran terbesar yang diangkat oleh para developer berpusat pada kurangnya benchmark performa query yang sesungguhnya. Meskipun pembuat gem mengklaim peningkatan kecepatan yang signifikan, benchmark hanya mengukur waktu kalkulasi hash, bukan eksekusi query yang lengkap. Para kritikus menunjukkan bahwa pendekatan ini gagal memperhitungkan apa yang terjadi selama operasi database sebenarnya, di mana catalog lookup hanya mewakili satu bagian dari keseluruhan proses query.
Komunitas sangat skeptis karena perbandingan performa hanya menunjukkan kalkulasi hash Ruby versus kalkulasi hash SQL, tanpa mendemonstrasikan peningkatan performa query end-to-end ketika melakukan query pada partition tertentu versus membiarkan PostgreSQL menangani seleksi partition secara otomatis.
Klaim Performa vs Realitas
- Peningkatan yang diklaim: 20-40x lebih cepat dalam kalkulasi hash
- Cakupan benchmark: Hanya waktu komputasi hash, bukan eksekusi query penuh
- Data yang hilang: Perbandingan performa query end-to-end
- Kekhawatiran komunitas: Tidak ada benchmark query dunia nyata yang disediakan
Risiko Maintenance dan Kompatibilitas
Beberapa developer telah menyoroti potensi mimpi buruk maintenance dari reimplementasi fungsi hash internal PostgreSQL. Pendekatan ini memerlukan sinkronisasi dengan detail implementasi internal PostgreSQL, yang dapat berubah antar versi. Hal ini menciptakan coupling yang ketat antara kode aplikasi dan versi PostgreSQL tertentu yang banyak dianggap mengkhawatirkan.
ini terlihat seperti mimpi buruk maintenance ke depannya, tapi saya bisa salah. Jika Anda terjebak pada versi pg tertentu untuk sementara waktu, mungkin ini layak dicoba.
Gem ini saat ini hanya mendukung partitioning berbasis integer (bigint, integer, smallint) dan tidak mendukung text, UUID, atau tipe data umum lainnya, yang semakin membatasi aplikabilitas praktisnya.
Keterbatasan Saat Ini dari Gem pg_hash_func
- Tipe yang didukung: bigint (int8), integer (int4), smallint (int2)
- Tipe yang tidak didukung: text/string, UUID, tipe data lainnya
- Platform: Ruby saja
- Ketergantungan versi PostgreSQL: Memerlukan sinkronisasi dengan perubahan implementasi internal
Strategi Optimasi yang Dipertanyakan
Anggota komunitas juga mempertanyakan premis fundamental dari optimasi ini. Hash partitioning biasanya dipilih secara khusus ketika Anda tidak mengetahui pola data sebelumnya, namun pendekatan ini memerlukan pengetahuan detail tentang kunci partition dan struktur. Hal ini tampaknya bertentangan dengan salah satu keunggulan utama hash partitioning - mendistribusikan data tanpa memerlukan analisis pola di awal.
Solusi yang diusulkan untuk menggunakan query SQL statis dengan fungsi hash yang hardcoded alih-alih rutinitas catalog PostgreSQL telah membuat beberapa developer bingung, karena hal ini memperkenalkan kompleksitas tambahan sambil berpotensi mengorbankan optimasi bawaan PostgreSQL.
Kesimpulan
Meskipun konsep optimasi query partition PostgreSQL bernilai, respons komunitas menunjukkan bahwa diperlukan benchmark yang lebih komprehensif dan pengujian dunia nyata untuk memvalidasi manfaat yang diklaim. Pendekatan ini mungkin memiliki manfaat untuk skenario high-throughput tertentu dengan versi PostgreSQL yang stabil, namun overhead maintenance dan cakupan yang terbatas menimbulkan pertanyaan tentang aplikabilitas yang lebih luas. Para developer tampaknya lebih tertarik untuk melihat perbandingan performa query yang sesungguhnya daripada benchmark kalkulasi hash yang terisolasi untuk mengevaluasi teknik optimasi ini dengan tepat.
Referensi: Bypass PostgreSQL catalog overhead with direct partition hash calculations