Untuk setiap versi Postgres yang mendukung pengindeksan hash , ada peringatan atau catatan bahwa indeks hash "mirip atau lebih lambat" atau "tidak lebih baik" dari indeks btree , setidaknya hingga versi 8.3. Dari dokumen:
Catatan: Karena utilitas indeks hash yang terbatas, indeks B-tree umumnya lebih disukai daripada indeks hash. Kami tidak memiliki bukti yang cukup bahwa indeks hash sebenarnya lebih cepat daripada B-tree bahkan untuk perbandingan =. Selain itu, indeks hash membutuhkan kunci yang lebih kasar; lihat Bagian 9.7.
Catatan: Pengujian telah menunjukkan indeks hash PostgreSQL sama atau lebih lambat dari indeks B-tree, dan ukuran indeks serta waktu pengembangan untuk indeks hash jauh lebih buruk. Indeks Hash juga mengalami kinerja yang buruk di bawah konkurensi tinggi. Karena alasan ini, penggunaan indeks hash tidak disarankan.
Catatan: Pengujian menunjukkan indeks hash PostgreSQL berkinerja tidak lebih baik daripada indeks B-tree, dan ukuran indeks serta waktu pengembangan untuk indeks hash jauh lebih buruk. Selain itu, operasi indeks hash saat ini tidak dicatat dalam WAL, jadi indeks hash mungkin perlu dibangun kembali dengan REINDEX setelah terjadi kerusakan basis data. Untuk alasan ini, penggunaan indeks hash saat ini tidak disarankan.
Di utas versi 8.0 ini , mereka mengklaim bahwa tidak pernah menemukan kasus di mana indeks hash sebenarnya lebih cepat daripada btree.
Bahkan dalam versi 9.2, perolehan kinerja untuk apa pun selain menulis indeks yang sebenarnya hampir tidak ada menurut posting blog ini (14 Maret 2016):
Indeks Hash pada Postgres oleh André Barbosa.
Pertanyaan saya, bagaimana mungkin?
Menurut definisi, indeks Hash adalah O(1)
operasi, di mana btree adalah O(log n)
operasi. Jadi bagaimana mungkin O(1)
pencarian lebih lambat daripada (atau bahkan mirip dengan) menemukan cabang yang benar, dan kemudian menemukan catatan yang benar?
Saya ingin tahu bagaimana dengan teori pengindeksan yang PERNAH memungkinkan!