ハッシュインデックスが等価検索でBtreeよりも速くならないのはなぜですか？

ハッシュインデックスをサポートするPostgresのすべてのバージョンについて、少なくともバージョン8.3までは、ハッシュインデックスがbtreeインデックスより「類似または遅い」または「良くない」という警告または注意があります。ドキュメントから：

バージョン7.2：

注：ハッシュインデックスのユーティリティは限られているため、通常はハッシュインデックスよりもBツリーインデックスの方が適しています。=比較の場合でも、ハッシュインデックスが実際に Bツリーよりも速いという十分な証拠はありません。さらに、ハッシュインデックスにはより粗いロックが必要です。セクション9.7を参照してください。

バージョン7.3（および8.2まで）：

注：テストの結果、PostgreSQLのハッシュインデックスはBツリーインデックスと同じかそれより遅いことがわかりました。また、ハッシュインデックスのインデックスサイズとビルド時間ははるかに悪いです。また、同時実行性が高いと、ハッシュインデックスのパフォーマンスが低下します。これらの理由により、ハッシュインデックスの使用はお勧めしません。

バージョン8.3：

注：テストは実行しないように、PostgreSQLのハッシュインデックスを示したは良い B-treeインデックスよりも、およびハッシュインデックスのインデックスサイズと構築時間ははるかに悪いです。さらに、ハッシュインデックス操作は現在WALログに記録されていないため、データベースクラッシュ後にハッシュインデックスをREINDEXで再構築する必要がある場合があります。これらの理由により、ハッシュインデックスの使用は現在推奨されていません。

このバージョン8.0のスレッドでは、ハッシュインデックスが実際にbtreeよりも高速であるケースを発見したことはなかったと主張しています。

バージョン9.2でさえ、このブログの投稿（2016年3月14日）によると、実際のインデックスを作成する以外のパフォーマンス向上はほとんどありませんでした：
AndréBarbosaによるPostgresのハッシュインデックス。

私の質問は、それはどのようにして可能ですか？

定義により、ハッシュインデックスはO(1)操作であり、btreeはO(log n)操作です。ではO(1)、正しいブランチを見つけてから正しいレコードを見つけるよりも、ルックアップの速度が遅い（またはそれに似ている）のはどうしてでしょうか。

索引付け理論について、それを可能にすることは決してありません。

ディスクベースのBtreeインデックスはO（log N）ですが、このソーラーシステムに適合するディスクアレイにはほとんど関係ありません。キャッシングのため、それらはほとんどが非常に大きな定数のO（1）と小さな定数のO（（log N）-1）です。正式には、それはO（log N）と同じです。なぜなら、定数は大きなO表記法では重要ではないからです。しかし、実際には重要です。

ハッシュインデックスルックアップの速度低下の多くは、ルックアップと同時にハッシュテーブルのサイズ変更が原因で発生する破損やデッドロックから保護する必要があるためです。最近のバージョン（言及するすべてのバージョンがコミカルに古くなっている）までは、この必要性により、定数がさらに高くなり、並行性がかなり低下しました。ハッシュ並行性よりもBTree並行性の最適化に費やされた作業時間が非常に多くなりました。

ハッシュルックアップは、理論的O(1)には、キーハッシュがターゲットレコードの物理的な場所に直接マッピングされる場合の操作です。Postgresでの動作は、私が正しく理解していれば、もう少し複雑です。キーハッシュは、探しているOIDを含むバケットにマッピングされます。バケットは複数のページで構成される可能性があり、特定のキー（ハッシュ）が見つかるまで順次スキャンする必要があります。これが、予想よりも遅く見える理由です。

ソースコードリポジトリ内のハッシュインデックスアクセス方法のREADMEファイルには、すべての詳細が含まれています。