Parameter biaya perencana
Ini memberi tahu saya bahwa random_page_cost . Anda dan seq_page_cost mungkin salah. Anda mungkin menggunakan penyimpanan dengan I/O acak cepat - baik karena sebagian besar database di-cache di RAM atau karena Anda menggunakan SSD, SAN dengan cache, atau penyimpanan lain yang I/O acaknya cepat.
Coba:
SET random_page_cost = 1;
SET seq_page_cost = 1.1;
untuk sangat mengurangi perbedaan param biaya dan kemudian dijalankan kembali. Jika berhasil, pertimbangkan untuk mengubah param tersebut di postgresql.conf. .
Estimasi jumlah baris Anda masuk akal, sehingga tidak terlihat seperti masalah salah estimasi perencana atau masalah dengan statistik tabel yang buruk.
Kueri salah
Permintaan Anda juga salah. OFFSET 0 LIMIT 1 tanpa ORDER BY akan menghasilkan hasil yang tidak terduga kecuali Anda dijamin memiliki tepat satu kecocokan, dalam hal ini OFFSET ... LIMIT ... klausa tidak diperlukan dan dapat dihapus seluruhnya.
Anda biasanya jauh lebih baik mengucapkan kueri seperti SELECT max(...) atau SELECT min(...) jika memungkinkan; PostgreSQL akan cenderung dapat menggunakan indeks untuk mengambil nilai yang diinginkan tanpa melakukan pemindaian tabel yang mahal atau pemindaian indeks dan pengurutan.
Kiat
BTW, untuk pertanyaan di masa mendatang, wiki PostgreSQL memiliki beberapa informasi bagus di kategori kinerja dan panduan untuk menanyakan Pertanyaan kueri lambat .
