Làm thế nào có thể để Hash Index không nhanh hơn Btree cho việc tra cứu bình đẳng?

Đối với mọi phiên bản Postgres hỗ trợ lập chỉ mục băm , có một cảnh báo hoặc lưu ý rằng các chỉ mục băm là "tương tự hoặc chậm hơn" hoặc "không tốt hơn" so với chỉ mục btree , ít nhất là lên đến phiên bản 8.3. Từ các tài liệu:

Phiên bản 7.2 :

Lưu ý: Do tiện ích hạn chế của các chỉ mục băm, chỉ mục cây B thường được ưu tiên hơn chỉ mục băm. Chúng tôi không có đủ bằng chứng cho thấy các chỉ số băm thực sự nhanh hơn các cây B ngay cả khi = so sánh. Hơn nữa, các chỉ số băm yêu cầu khóa thô hơn; xem mục 9.7.

Phiên bản 7.3 (và lên đến 8.2) :

Lưu ý: Việc kiểm tra đã cho thấy các chỉ mục băm của PostgreQuery tương tự hoặc chậm hơn các chỉ mục của cây B và kích thước chỉ mục và thời gian xây dựng cho các chỉ mục băm tồi tệ hơn nhiều. Các chỉ số băm cũng chịu hiệu suất kém dưới sự đồng thời cao. Vì những lý do này, việc sử dụng chỉ số băm không được khuyến khích.

Phiên bản 8.3 :

Lưu ý: Việc kiểm tra đã cho thấy các chỉ mục băm của PostgreQuery hoạt động không tốt hơn các chỉ mục của cây B và kích thước chỉ mục và thời gian xây dựng cho các chỉ mục băm tồi tệ hơn nhiều. Hơn nữa, các hoạt động chỉ mục băm hiện không được ghi nhật ký WAL, vì vậy các chỉ mục băm có thể cần phải được xây dựng lại với REINDEX sau khi sự cố cơ sở dữ liệu. Vì những lý do này, việc sử dụng chỉ số băm hiện không được khuyến khích.

Trong chủ đề phiên bản 8.0 này , họ tuyên bố rằng chưa bao giờ tìm thấy trường hợp chỉ số băm thực sự nhanh hơn btree.

Ngay cả trong phiên bản 9.2, hiệu suất đạt được cho bất cứ điều gì ngoài việc viết chỉ mục thực tế gần như không có gì theo bài đăng trên blog này (14 tháng 3 năm 2016):
Hash Indexes trên Postgres của André Barbosa.

Câu hỏi của tôi là làm thế nào là có thể?

Theo định nghĩa, các chỉ mục Hash là một O(1)hoạt động, trong đó btree là một O(log n)hoạt động. Vì vậy, làm thế nào có thể một O(1)tra cứu chậm hơn (hoặc thậm chí tương tự như) tìm đúng nhánh, và sau đó tìm bản ghi chính xác?

Tôi muốn biết những gì về lý thuyết lập chỉ mục EVER có thể biến điều đó thành khả năng!

Các chỉ số Btree dựa trên đĩa thực sự là O (log N), nhưng điều đó không liên quan nhiều đến các mảng đĩa phù hợp với hệ mặt trời này. Do bộ nhớ đệm, chúng chủ yếu là O (1) với hằng số rất lớn cộng với O ((log N) -1) với hằng số nhỏ. Chính thức, đó là điều tương tự như O (log N), bởi vì hằng số không quan trọng trong ký hiệu O lớn. Nhưng họ làm vấn đề trong thực tế.

Phần lớn sự chậm lại trong việc tra cứu chỉ số băm xuất phát từ nhu cầu bảo vệ chống tham nhũng hoặc bế tắc do thay đổi kích thước bảng băm đồng thời với việc tra cứu. Cho đến khi các phiên bản gần đây (mọi phiên bản bạn đề cập đã hết thời), nhu cầu này dẫn đến các hằng số cao hơn và đồng thời khá kém. Nhiều giờ hơn đã đi vào việc tối ưu hóa đồng thời BTree hơn là đồng thời băm.

Tra cứu băm về mặt lý thuyết là một O(1)hoạt động khi hàm băm chính ánh xạ trực tiếp đến vị trí thực của bản ghi đích. Cách nó hoạt động trong Postgres, nếu tôi hiểu chính xác, thì phức tạp hơn một chút: hàm băm chính ánh xạ tới một thùng chứa OID mà bạn đang tìm kiếm. Một nhóm có khả năng có thể chứa nhiều hơn một trang mà bạn cần quét tuần tự cho đến khi bạn tìm thấy khóa cụ thể (hàm băm) của mình. Đây là lý do tại sao nó xuất hiện chậm hơn bạn mong đợi.

Phương thức truy cập chỉ mục băm Tệp README trong repo mã nguồn có tất cả các chi tiết.