Training Model AI 4B untuk Optimasi Query Postgres: Reduksi Latensi 44 Persen

Optimasi query database relasional seperti PostgreSQL selama puluhan tahun mengandalkan heuristic planner berbasis estimasi biaya atau yang dikenal sebagai cost-based optimizer. Planner bawaan Postgres bertugas menganalisis statistik tabel, ukuran page di disk, histogram distribusi kolom, dan korelasi data untuk menentukan dua hal krusial: urutan join antar tabel (join ordering) dan metode akses data fisik (index scan, bitmap heap scan, atau sequential scan). Namun, masalah join ordering secara matematis tergolong masalah komputasi NP-hard, dan estimasi kardinalitas sering kali meleset drastis ketika query melibatkan banyak tabel relasional kompleks dengan filter multi-kondisi yang saling bergantung.

Riset empiris terbaru yang dipublikasikan oleh engineer machine learning Rohan Bansal pada pertengahan September 2026 membuktikan terobosan yang sangat menjanjikan bagi arsitektur database modern. Sebuah model bahasa open-weights berukuran kompak (4B parameter, berbasis fondasi keluarga Qwen) berhasil dilatih khusus menggunakan perpaduan teknik supervised fine-tuning (SFT) dan agentic reinforcement learning (RL) untuk mengarahkan rencana eksekusi PostgreSQL. Hasil evaluasi komprehensif pada 113 query join-heavy berskala besar dari benchmark IMDb mencatatkan reduksi latensi eksekusi agregat sebesar 44,7 persen, di mana sejumlah query kompleks bahkan berhasil dieksekusi hingga 81 persen lebih cepat dibandingkan rencana default yang dipilih oleh query planner bawaan Postgres.

Keterbatasan Fundamental Cost-Based Optimizer Tradisional

Sebelum mendalami arsitektur pelatihan model 4B, penting untuk menelaah secara kritis mengapa query optimizer tradisional yang telah dikembangkan selama puluhan tahun kerap gagal menghasilkan rencana optimal. Pertanyaan mengenai seberapa andal cost-based optimizer sesungguhnya telah diuji secara mendalam oleh Leis et al. sejak tahun 2015 melalui Join Order Benchmark (JOB), dan kemudian dievaluasi kembali satu dekade kemudian. Kesimpulan dari riset akademis tersebut tetap konsisten: estimasi biaya kalkulasi matematis yang dibuat oleh database engine sering kali memiliki deviasi sangat besar terhadap waktu eksekusi riil di tingkat sistem operasi.

Penyebab paling mendasar dari kegagalan ini adalah dua asumsi penyederhanaan yang terpaksa diambil oleh engine database: asumsi independensi nilai atribut (attribute value independence) dan asumsi keseragaman distribusi data (uniformity assumption). Ketika sebuah query SQL analitik menggabungkan lima atau enam tabel relasional sekaligus, misalnya menggabungkan tabel master film, data relasi perusahaan produksi, dan direktori kategori perusahaan, Postgres mencoba memperkirakan berapa perkiraan baris data yang akan lolos dari setiap tahapan join bertingkat.

Kesalahan estimasi kardinalitas yang tampaknya sepele pada join pertama akan berlipat ganda secara eksponensial pada tahapan join berikutnya. Akibatnya, optimizer Postgres sering kali keliru memilih algoritma Nested Loop Join dengan asumsi bahwa data perantara hanya berjumlah puluhan baris, padahal pada kenyataan eksekusi data tersebut mencapai ratusan ribu baris. Kondisi ini memaksa engine database melakukan jutaan pencarian indeks berulang yang memicu lonjakan I/O disk secara masif dan memperlambat throughput sistem backend.

Di sisi lain, mengevaluasi apakah sebuah query plan bernilai baik atau buruk memiliki karakteristik yang sangat unik dalam rekayasa perangkat lunak: ia memiliki metrik keberhasilan objektif yang sangat mudah diukur, yaitu waktu eksekusi nyata (runtime latency). Jika rencana A berhasil menyelesaikan query dalam waktu 74 milidetik sementara rencana default B membutuhkan 118 milidetik, maka rencana A secara definitif dan terukur lebih unggul. Karakteristik domain masalah dengan verifikasi cepat, deterministik, dan dapat diuji secara otomatis inilah yang menjadikan optimasi query sebagai kandidat sempurna bagi penerapan reinforcement learning.

Arsitektur Pelatihan: Distilasi SFT dan Agentic Reinforcement Learning

Melatih model AI 4B agar mampu mengarahkan PostgreSQL tidak dilakukan dengan meminta model menulis ulang sintaks SQL mentah secara bebas. Pendekatan menulis ulang query SQL sering kali berisiko mengubah semantik hasil data atau memicu syntax error yang tidak diinginkan oleh aplikasi bisnis. Selain itu, PostgreSQL sendiri tidak mendukung mekanisme intervensi rencana eksekusi secara native tanpa dependensi tambahan. Oleh karena itu, arsitektur ini memanfaatkan ekstensi tepercaya bernama pg_hint_plan.

Ekstensi pg_hint_plan memungkinkan planner Postgres menerima instruksi deklaratif spesifik yang disisipkan melalui komentar SQL, seperti /*+ HashJoin(mc cn) Leading((cn mc) t) */. Melalui mekanisme ini, query SQL asli tetap utuh 100 persen, sementara urutan join dan metode pemindaian diarahkan secara presisi oleh hint yang dihasilkan oleh model AI.

Pipeline pelatihan dirancang melalui dua tahapan berurutan yang saling melengkapi:

1. Off-Policy Distillation (Supervised Fine-Tuning): Pada kondisi awal (untrained), model 4B murni belum memiliki representasi memori mengenai skema database relasional maupun sintaks deklaratif pg_hint_plan. Bahkan, model mentah gagal menghasilkan rencana valid untuk 99 dari 113 query uji coba. Untuk memberikan pemahaman dasar, peneliti melakukan distilasi pengetahuan dari sekitar 500 trajektori penalaran model frontier berukuran besar. Pembobotan model disesuaikan secara efisien menggunakan Low-Rank Adaptation (LoRA), sehingga model 4B menguasai representasi struktural pemetaan foreign key dan sintaks hint yang valid.
2. Agentic Reinforcement Learning (RL Rollouts): Setelah model menguasai pembuatan sintaks yang valid, fase pembelajaran mandiri (RL) dimulai. Untuk setiap query SQL dalam dataset pengujian, sistem menjalankan empat rollout penalaran secara paralel. Setiap rollout menghasilkan kandidat kombinasi join dan scan yang berbeda, lalu langsung mengirimkannya ke cluster PostgreSQL untuk diuji waktu eksekusi riilnya melawan eksekusi baseline rencana bawaan Postgres.

Untuk menghitung pembaruan bobot model, peneliti merancang varian algoritma Group Relative Policy Optimization (GRPO) yang disesuaikan secara khusus dengan karakteristik noise database. Karena latensi server database dipengaruhi oleh banyak faktor non-algoritmik, model tidak dinilai dari angka milidetik absolut, melainkan dari keunggulan relatif (relative advantage) terhadap rencana baseline pada pengujian yang setara.

Mengatasi Variansi Runtime dan Linux Page Cache Contention

Salah satu tantangan paling rumit dalam menerapkan reinforcement learning pada sistem fisik database adalah non-determinisme lingkungan operasi. Durasi eksekusi query SQL di server Linux sangat bergantung pada apakah halaman data (pages) yang dibutuhkan sudah berada di dalam RAM (page cache hit) atau harus dibaca secara fisik dari media penyimpanan SSD NVMe (cold disk read). Apabila sebuah rollout kebetulan dieksekusi sesaat setelah rollout lain membaca tabel yang sama, eksekusinya akan tampak jauh lebih cepat semata-mata karena data sudah hangat di memory cache, bukan karena rencana join-nya lebih cerdas.

Jika noise lingkungan ini dibiarkan masuk ke dalam fungsi reward RL, model AI akan mengalami degradasi performa karena mempelajari ilusi optimasi palsu. Untuk memitigasi risiko tersebut, infrastruktur pengujian dibangun dengan isolasi ketat:

• Isolasi Memori Kontainer Tingkat Kernel: Node database PostgreSQL dijalankan pada empat kontainer terpisah yang dilengkapi alokasi cgroup memori dan isolasi inti CPU mandiri, terpisah sepenuhnya dari server inferensi vLLM yang menjalankan GPU Nvidia H100.
• Sinkronisasi dan Pembersihan Buffer Cache: Setiap kali pengujian kandidat query dilakukan, sistem mengeksekusi instruksi sinkronisasi buffer Postgres dan pembersihan cache halaman kernel Linux secara terkoordinasi (posix_fadvise) untuk menjamin kondisi awal pembacaan data selalu berada pada status baseline yang identik.
• Penalti Query Timeout dan Rencana Gagal: Kandidat hint yang menghasilkan regresi performa ekstrem atau melebihi batas waktu eksekusi (timeout threshold) secara otomatis dijatuhi penalti reward skalar negatif yang signifikan. Hal ini melatih model untuk berhati-hati dan menghindari rencana join berisiko tinggi.

Hasil Evaluasi Empiris pada Dataset IMDb dan Beban Kerja Nyata

Kinerja model 4B setelah melalui proses post-training SFT dan RL rollouts menunjukkan peningkatan efisiensi yang sangat konsisten di seluruh spektrum pengujian. Pada query standar yang melibatkan join antar tabel relasional seperti title, movie_companies, company_name, dan company_type, model mampu mengenali pola selektivitas data yang sering luput dari histogram statistik Postgres.

Sebagai contoh kasus konkret, pada query yang mencari daftar perusahaan produksi asal Jepang yang paling aktif merilis judul film pada dekade 2000-an, optimizer bawaan Postgres cenderung mendahulukan pemindaian tabel junction movie_companies dengan asumsi indeks standar akan mempercepat filter. Akibatnya, Postgres membutuhkan waktu eksekusi sebesar 118 milidetik.

Model 4B yang telah dilatih mengidentifikasi bahwa filter rentang tahun pada tabel title dan filter kode negara pada tabel company_name dapat disaring terlebih dahulu secara simultan sebelum digabungkan dengan tabel junction. Dengan menyisipkan instruksi /*+ Leading((cn mc) t) HashJoin(mc cn) */, model berhasil mereduksi durasi eksekusi query menjadi hanya 74 milidetik, atau mengalami percepatan sekitar 37 persen pada satu query tunggal. Secara keseluruhan, total waktu pemrosesan beban kerja (workload execution time) dari 113 query kompleks berkurang drastis hingga 44,7 persen.

Panduan Implementasi Arsitektur bagi Tim Data Engineering

Bagi tim backend dan data engineering yang mengelola database PostgreSQL berkapasitas besar dengan beban analitik yang intensif, keberhasilan eksperimen ini menawarkan cetak biru praktis untuk mengoptimalkan infrastruktur tanpa perlu merombak aplikasi secara menyeluruh:

1. Audit Query Beban Tinggi via pg_stat_statements: Langkah awal yang wajib dilakukan adalah mengidentifikasi 10 hingga 20 query analitik terberat yang memakan porsi resource CPU dan I/O terbesar di server produksi melalui modul resmi pg_stat_statements.
2. Evaluasi Deviasi Cost vs Actual Time: Jalankan perintah EXPLAIN (ANALYZE, BUFFERS) pada query target untuk melihat apakah terdapat ketimpangan tajam antara angka cost estimasi planner dengan actual time di lapangan. Ketimpangan ini menandakan histogram statistik tabel gagal membaca korelasi data.
3. Integrasi Model Inferensi pada Lapisan Database Proxy: Model open-weights 4B parameter dapat dideploy menggunakan runtime inferensi CPU atau akselerator ringan pada instance proxy database, misalnya menggunakan arsitektur PgBouncer atau kustom middleware proxy. Proxy bertugas menerima query masuk dari aplikasi backend, meminta saran hint dari model 4B secara sub-milidetik, menyisipkan komentar hint, lalu meneruskannya ke database utama.
4. Keamanan Data Terjaga Penuh: Keuntungan terbesar dari pendekatan ini dibanding layanan cloud proprietary adalah kepatuhan privasi (data governance). Model AI hanya memproses struktur sintaks SQL dan nama kolom relasional tanpa pernah melihat, membaca, atau menyimpan data sensitif pengguna (zero customer records exposure).

Eksperimen integrasi model 4B dengan PostgreSQL membuktikan bahwa masa depan optimasi sistem komputasi berkinerja tinggi terletak pada konvergensi harmonis antara engine database tradisional yang kokoh dan agen kecerdasan buatan spesialis yang adaptif terhadap pola data dunia nyata.

Rekomendasi Tools & Layanan

Mau langsung nyobain AI yang dibahas di artikel ini tanpa setup ribet? AI token plan Alibaba Cloud ngasih akses ke Qwen, DeepSeek, dan model lain lewat satu API dan platform Qwen buat build agent sendiri. Free tier-nya cukup buat eksperimen pertama.