Mengoptimalkan Query Lambat PostgreSQL dimulai dengan mengidentifikasi akar masalah secepat mungkin. Dalam 1–2 kalimat ini kita memetakan langkah langsung: buka sesi SQLi di Emacs, lihat tabel pg_stat_statements, kemudian jalankan EXPLAIN ANALYZE pada kandidat query. Artikel ini menunjukkan workflow Emacs lengkap untuk DevOps/database engineer agar triase hingga perbaikan bisa berlangsung dari satu lingkungan editor.

Menyiapkan Workflow Emacs dengan SQL-mode/SQLi

Emacs masih relevan sebagai konsol terpadu jika Anda sudah memanfaatkan sql-mode. Pastikan koneksi tersimpan dalam .dir-locals.el atau sql-connection-alist supaya perintah SQL langsung dieksekusi di buffer *SQL*. Contoh pemanggilan:

(require 'sql)
(setq sql-connection-alist
      '((pg-main
         (sql-product 'postgres)
         (sql-user "deploy")
         (sql-database "production")
         (sql-server "db.example.com"))))
(sql-connect 'pg-main)

Setelah terhubung, Anda bisa mengetik pg_stat_statements secara langsung, menyimpan hasil ke buffer, dan membaginya dengan tim lewat snippet Emacs.

Langkah Triage: Kapan Query Lambat dan Apa Tandanya

Triase cepat menghindari membuang energi pada perubahan yang tidak perlu. Sekilas, cari pola berikut di pg_stat_statements:

  • Flux offset pagination: jumlah OFFSET melebihi ribuan atau tidak ter-cutoff oleh indeks. Flag ini berarti kebutuhan untuk keyset pagination agar PostgreSQL tidak membaca tabel penuh.
  • Bottleneck join: shared_blks_read dan temp_blks_written meningkat tajam pada query join. Periksa apakah joining column punya indeks yang tepat.
  • Growth data: query yang satu per satu tumbuh waktu karena data historis makin berat. Ini bisa menuntut partial index, partition, atau cleanup vacuum-analyze lebih sering.

Dokumentasikan hasil key metrics langsung di buffer Emacs sehingga bisa dibandingkan antar iterasi optimasi.

Menganalisis Query dengan EXPLAIN ANALYZE di Emacs

Setelah triase, salin query ke buffer baru lalu jalankan EXPLAIN ANALYZE. Contoh sederhana:

EXPLAIN ANALYZE
SELECT o.id, o.total
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE c.region = 'APAC'
AND o.created_at >= current_date - interval '30 days';

Perhatikan urutan langkah berikut:

  1. Node bottleneck: lihat apakah nested loop, hash join, atau sequential scan mendominasi waktu.
  2. Filter order: pastikan filter kolom dengan selektivitas tinggi diletakkan lebih awal.
  3. Lookup indeks: apakah tabel yang bergabung benar-benar memanfaatkan indeks? Jika tidak, pertimbangkan covering index atau rewrite query.

Gunakan Emacs overlay atau imenu untuk menandai bagian EXPLAIN sehingga Anda dapat membandingkan versi query di buffer yang sama.

Rekomendasi Optimasi: Indeks, Vacuum, dan Rewrite

Beberapa tindakan nyata:

  • Partial index: jika filter Anda selalu memeriksa kondisi tetap (contoh: status = 'active'), buat indeks partial yang hanya menampung baris tersebut agar index scan lebih ringan.
  • VACUUM/ANALYZE rutin: jalankan dari buffer SQL Emacs dengan VACUUM ANALYZE schema.table; untuk memastikan estimate planner akurat.
  • Rewrite query: hindari fungsi di kolom indeks atau SELECT *. Fokus pada kolom yang benar-benar dibutuhkan.

Jangan lupa mencatat sebelum dan sesudah optimasi di Emacs, lalu bandingkan total_time dari EXPLAIN ANALYZE.

Automasi Logging dan Alert di Emacs

Emacs bisa mengekspor hasil monitoring ke file log sederhana dan memicu notifikasi saat query tertentu melewati threshold. Contoh snippet:

(defun log-pg-slow-query (query duration)
  (with-temp-buffer
    (insert (format "%s | %s | %sms\n" (current-time-string) duration query))
    (write-region (point-min) (point-max)
                  "~/logs/pg-slow-queries.log" t)))

(defun alert-on-slow-query (query duration-threshold)
  (let ((duration (run-sql-and-fetch-duration query)))
    (when (> duration duration-threshold)
      (log-pg-slow-query query duration)
      (message "Query lambat: %s (%.2f ms)" query duration))))

Integrasikan fungsi-fungsi ini dengan sql-send-buffer untuk menjalankan query dan mengecek durasinya. Anda juga bisa menetapkan run-at-time agar Emacs memeriksa statistik setiap jam.

Kesimpulan dan Praktik Terbaik

Workflow Emacs memungkinkan Anda memusatkan triase, analisis, dan automasi monitoring query lambat PostgreSQL tanpa beralih context. Dari pg_stat_statements hingga rekomendasi indeks partial, pencatatan hasil di buffer SQL, serta alert berbasis elisp, semua bergerak dalam satu editor yang sama. Kunci utamanya adalah menempelkan metrik triase ke praktik nyata—meminimalisir OFFSET berat, mengenali join yang butuh indeks, dan menjaga planner tetap terinformasi lewat VACUUM ANALYZE.

Dengan pendekatan ini, debugging query nyata bisa lebih cepat karena Anda langsung melihat data performa dan mencatat tindak lanjut, bukan hanya menebak masalahnya.