PostgreSQL Index Advisor

• Ekstensi PostgreSQL oleh Supabse yang merekomendasikan indeks untuk meningkatkan performa kueri
• Jika kueri diberikan ke fungsi index_advisor(), fungsi ini mengembalikan biaya sebelum/sesudah untuk startup/keseluruhan serta SQL DDL untuk membuat indeks
  • Menjalankan: select * from index_advisor('select book.id from book where title = $1');
  • Hasil: {"CREATE INDEX ON public.book USING btree (title)"}
• Untuk kueri yang kompleks, terkadang mengembalikan beberapa pernyataan pembuatan indeks
• Mendukung parameter generik ($1, $2, ..)
• Mendukung Materialized View
• Dapat mengidentifikasi tabel/kolom yang tersembunyi oleh view

[savvykang]

Pada versi saat ini, hanya indeks btree dengan satu kolom yang direkomendasikan. Jika kondisi kueri menjadi kompleks atau Anda menggunakan pencarian full text, ini tidak dapat digunakan https://supabase.com/docs/guides/…

[savvykang]

Katanya, saat kondisi pencarian kompleks, yang digunakan adalah beberapa indeks kolom tunggal alih-alih indeks multikolom, tetapi tampaknya keduanya tidak bekerja dengan cara yang benar-benar sama. Atau, ada juga yang mengatakan bahwa dalam situasi tertentu, menggunakan indeks multikolom dan beberapa indeks kolom tunggal secara bersamaan adalah pilihan terbaik.

https://www.postgresql.org/docs/current/indexes-bitmap-scans.html

[xguru]

Komentar Hacker News

• Akan bagus jika ada fitur yang merekomendasikan tipe data yang lebih efisien berdasarkan data yang benar-benar tersimpan di tabel
• Akan bagus jika ada database yang secara otomatis mendeteksi kueri lambat dan membuat indeks yang diperlukan
  • Menjalankan load test dari aplikasi akan memanggil database dan mengumpulkan kueri, lalu database menyesuaikan diri secara otomatis
• Tidak tahu bahwa HypoPG sudah bisa digunakan di RDS selama lebih dari 1 tahun
• Ingin memakai indeks pada satu relation dalam join 3 tabel atau lebih, tetapi jika tidak memberi limit pada CTE, Postgres mencoba menjalankan setiap join secara paralel dan berusaha menggabungkan sangat banyak baris
  • Akhir-akhir ini rasanya berurusan dengan query planner membuat ingin berpisah dengan pg
• CockroachDB memiliki fitur serupa yang sudah tertanam
  • Mengambil kueri lama yang lambat lalu menganalisis dan menyarankan indeks virtual untuk rencana kueri yang lebih baik
  • Bisa ditambahkan dengan satu klik dari UI konsol
• Di mesin kueri terdistribusi seperti Presto atau Spark, pekerjaan serupa dilakukan dengan memakai partisi dan bucket alih-alih indeks
  • Ini dapat mengurangi komputasi, waktu, dan biaya
• Ditulis dengan Vanilla Pl/PgSQL sehingga praktis
  • Ada godaan untuk menyalin fungsi index_advisor(text) ke sesi dan mulai melakukan hard-coding serta heuristik
  • Sebagian besar ekstensi yang berarti perlu dikompilasi, dipasang, dibuat, dan dihapus
• Mirip dengan TiAdvisor milik TiDB, dan menggunakan metode virtual
• Sedang menggunakan pghero, dan ini menyediakan fitur tersebut lewat GUI
• Sepertinya tidak memberikan pertimbangan atau wawasan tentang trade-off yang terkait
  • Ekstensi dasarnya, HypoPG, tampaknya tidak mengumpulkan statistik tentang data yang memengaruhi query planner
• Penasaran apakah ini mengenali tabel induk dan tabel anak yang diwarisi