タグ付けされた質問 「btree」

順序（1、2、3、4、5）のキーを持つレコードを、最初は空のB + –次数m = 3のツリーに入力した結果を表示します。オーバーフローの場合は、ノードを分割し、再配布しないでください隣人への鍵。木の高さを低くするために、キーを使用してレコードを異なる順序で入力することは可能ですか？ 以下からの動的な木構造組織、P.50：リレーショナルDBMSの内部、第5章 私はこれが得意ではありませんが、左側で≤、右側で>を実行しようとしました： 1,2の挿入まで： 次に、ノードを分割し、近隣にキーを再配布しないようにする必要がある限り（私はそれを息子ノードとして理解しています）、2のセルの右側にのみ挿入しました。 そして、私は5を挿入するときと同じことを続けました： しかし、これはかなり奇妙です。これらのような空のノードを見たことがありません...そして、それがいくつかの非常に基本的なBツリープロパティを尊重するかどうかわかりません： 各ノードは最大で（m-1）個のキーを持ち、少なくとも（⌈（m / 2）⌉-1）個のキーを持ちます。 最初の試み：注文のエラーにより、あいまいなツリーが明らかになりました 最初に、「順序」が何であるか（ノードあたりの子の最大数）を誤解しました。したがって、ノードには3つのスペース（したがって、4つの子）を含めることができると思いました。次数4のツリーを作成していたと思います。 1,2,3の挿入まで： 4を挿入して、ノードを分割し、キーを近隣に再配布しない限り（これは矛盾しているようです）、3の後の右側の葉に1,2,3および4,5を割り当てます。

11 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)、正しいブランチを見つけてから正しいレコードを見つけるよりも、ルックアップの速度が遅い（またはそれに似ている）のはどうしてでしょうか。 索引付け理論について、それを可能にすることは決してありません。

8 postgresql  index  btree  hashing