Meskipun tidak berguna untuk rencana sederhana seperti ini, http://explain.depesz.com sangat berguna. Lihat http://explain.depesz.com/s/t4fi. Perhatikan tab "statistik" dan tarik-turun "opsi".
Hal-hal yang perlu diperhatikan tentang rencana ini:
-
Perkiraan jumlah baris (183) cukup sebanding dengan jumlah baris sebenarnya (25). Ini tidak ratusan kali lebih banyak, juga bukan 1. Anda lebih tertarik pada urutan besarnya dalam hal perkiraan jumlah baris, atau masalah "1 vs bukan 1". (Anda bahkan tidak perlu akurasi "cukup dekat untuk pekerjaan pemerintah" - "cukup dekat untuk akuntansi kontrak militer" sudah cukup). Perkiraan selektivitas dan statistik tampaknya masuk akal.
-
Ini menggunakan indeks parsial dua kolom yang disediakan (
index scan using index_cars_onsale_on_brand_and_model_name), sehingga cocok dengan kondisi indeks parsial. Anda dapat melihatnya diFilter: has_auto_gear. Kondisi pencarian indeks juga ditampilkan. -
Kinerja kueri terlihat masuk akal mengingat jumlah baris tabel akan berarti indeksnya cukup besar, terutama karena lebih dari dua kolom. Baris yang cocok akan tersebar, jadi kemungkinan setiap baris akan membutuhkan halaman yang terpisah untuk dibaca juga.
Saya tidak melihat ada yang salah di sini. Kueri ini kemungkinan besar akan mendapat manfaat besar dari pemindaian hanya indeks PostgreSQL 9.2.
Mungkin saja ada beberapa tabel yang mengasapi di sini, tetapi mengingat indeks 2 kolom dan banyaknya baris, waktu respons tidak sepenuhnya tidak masuk akal, terutama untuk tabel dengan 170 (!!) kolom yang cenderung memuat relatif sedikit tupel ke masing-masing halaman. Jika Anda mampu membayar waktu henti, coba VACUUM FULL untuk mengatur ulang tabel dan membangun kembali indeks. Ini secara eksklusif akan mengunci tabel untuk beberapa waktu sementara itu membangunnya kembali. Jika Anda tidak mampu membayar waktu henti, lihat pg_reorg dan/atau CREATE INDEX CONCURRENTLY dan ALTER INDEX ... RENAME TO .
Anda mungkin menemukan EXPLAIN (ANALYZE, BUFFERS, VERBOSE) terkadang lebih informatif, karena dapat menunjukkan akses buffer, dll.
Salah satu opsi yang dapat membuat kueri ini lebih cepat (meskipun berisiko memperlambat kueri lain) adalah dengan mempartisi tabel pada brand dan aktifkan constraint_exclusion . Lihat partisi.
