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.

TL;DR

• Model bahasa open-weights berukuran 4B parameter berbasis keluarga Qwen berhasil dilatih menggunakan supervised fine-tuning (SFT) dan agentic reinforcement learning untuk mengarahkan rencana eksekusi PostgreSQL.
• Evaluasi pada 113 query join-heavy dari benchmark IMDb mencatatkan reduksi latensi eksekusi agregat sebesar 44,7 persen, dengan sejumlah query kompleks hingga 81 persen lebih cepat.
• Model tidak menulis ulang SQL, melainkan menghasilkan hint melalui ekstensi pg_hint_plan sehingga query asli tetap utuh 100 persen.
• Pelatihan RL menggunakan varian GRPO yang menilai keunggulan relatif terhadap baseline, dengan isolasi cgroup memori, empat kontainer database terpisah, dan pembersihan page cache untuk menangani noise variansi runtime.
• Pada contoh kasus query perusahaan produksi Jepang, model mereduksi waktu eksekusi dari 118 milidetik menjadi 74 milidetik, atau percepatan sekitar 37 persen.

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.

Perbandingan Cost-Based Optimizer Bawaan Postgres vs Model AI 4B denga

Aspek	Planner Bawaan Postgres	Model AI 4B + pg_hint_plan
Dasar keputusan rencana	Estimasi biaya, histogram, dan statistik tabel	Waktu eksekusi riil via reinforcement learning
Asumsi penyederhanaan	Independensi atribut dan distribusi seragam	Belajar dari pola selektivitas data nyata
Total latensi 113 query IMDb	Baseline rencana default	Reduksi agregat 44,7 persen
Query kompleks tercepat	Waktu eksekusi baseline	Hingga 81 persen lebih cepat
Query perusahaan produksi Jepang	118 milidetik	74 milidetik, percepatan 37 persen
Risiko utama	Salah pilih Nested Loop Join, lonjakan I/O	Penalti reward untuk timeout dan rencana gagal

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.

FAQ

Mengapa query planner bawaan PostgreSQL sering menghasilkan rencana eksekusi yang lambat?

Planner bawaan Postgres mengandalkan cost-based estimasi dengan asumsi independensi nilai atribut dan keseragaman distribusi data, sehingga kesalahan estimasi kardinalitas berlipat ganda secara eksponensial pada join bertingkat. Akibatnya optimizer bisa salah memilih algoritma seperti Nested Loop Join padahal data perantara mencapai ratusan ribu baris.

Bagaimana cara model AI 4B mengarahkan rencana eksekusi PostgreSQL tanpa mengubah query SQL?

Model memanfaatkan ekstensi pg_hint_plan yang menerima instruksi deklaratif melalui komentar SQL, seperti /*+ HashJoin(mc cn) Leading((cn mc) t) */. Dengan mekanisme ini query SQL asli tetap utuh 100 persen sementara urutan join dan metode pemindaian diarahkan secara presisi.

Apa saja tahapan pipeline pelatihan model 4B ini?

Tahap pertama adalah off-policy distillation atau supervised fine-tuning dengan sekitar 500 trajektori penalaran model frontier menggunakan LoRA, karena model mentah gagal menghasilkan rencana valid untuk 99 dari 113 query. Tahap kedua adalah agentic reinforcement learning dengan empat rollout paralel per query yang diuji langsung waktu eksekusinya terhadap baseline Postgres.

Bagaimana peneliti mengatasi noise variansi runtime akibat Linux page cache?

Infrastruktur pengujian menjalankan empat kontainer PostgreSQL terpisah dengan alokasi cgroup memori dan isolasi inti CPU, terpisah dari server inferensi vLLM di GPU Nvidia H100. Sistem juga mengeksekusi sinkronisasi buffer Postgres dan pembersihan cache halaman kernel Linux via posix_fadvise agar kondisi awal pembacaan data selalu identik.

Bagaimana langkah implementasi arsitektur ini bagi tim data engineering?

Mulai dengan mengaudit 10 hingga 20 query analitik terberat via pg_stat_statements, lalu evaluasi deviasi cost vs actual time menggunakan EXPLAIN (ANALYZE, BUFFERS). Selanjutnya deploy model 4B pada lapisan proxy database seperti PgBouncer untuk menyisipkan hint sub-milidetik, dengan keuntungan zero customer records exposure karena model hanya memproses sintaks SQL dan nama kolom.

Sumber & Referensi

Rujukan resmi yang dipakai untuk memverifikasi klaim di artikel ini:

• Konfigurasi Query Tuning PostgreSQL
• Repositori ekstensi pg_hint_plan
• Halaman resmi model Qwen