なぜpostgresqlはハッシュインデックスを "無視する"のですか？

Question

私はpostgresqlがハッシュインデックスを使用していることを知らないことを知っています。彼らは実際に言う：

「注意ハッシュインデックス操作は現在WAL-ログインしていません、ハッシュので インデックスは、データベースのクラッシュ後REINDEXを再構築する必要があるかもしれません 彼らはまた、ストリーミングやファイルベースの上に複製されません。 これらの理由から、現在、ハッシュインデックスの使用は推奨されていません。

これは、まったく使用しないのが良い引数ですが、私はpostgresql開発者がハッシュインデックスをファーストクラスの市民にしようとしない理由を理解できません。まったくそれをする。

実際に等価を検索する必要がある場合は、o（1）で検索、挿入、削除を行うため、ハッシュインデックスはどの種類のツリーよりもはるかに優れている必要があります。 o（log（n））。最悪のケースでは、ハッシュインデックスはo（n）に対して機能する可能性がありますが、最悪の場合を避けるための既知の技術がたくさんあります。私がdbエンジンのアーキテクトだった場合、そのような議論は、ハッシュインデックスを実行可能な選択肢にするという私の決定を確実に支配するはずですが、postgresqlではそれは違うようです。これに技術的な理由があるのですか、あるいはそのような決定は技術的に動機付けられていませんか？

Answer 1

木のインデックスは、たとえばB ⁺のツリーとその変形を使用すると、木の高さcが小さい定数であるO（c）のコストを考慮すると非常に効率的ですc = 3または4の場合、数百万のレコードを索引付けできます）、通常は少なくとも1つまたは2つのレベルのキャッシュがキャッシュされるため、ディスクアクセスの数はほとんどの場合1または2に等しくなります。

したがって、実用上、ハッシュインデックスと同様のパフォーマンスを持ち、さらに範囲検索を可能にするという大きな利点があります。