私は最近、Postgres データベースの最適化に取り組んでおり、伝統的に B-Tree インデックスしか使用していません。ただし、Postgres 8.3 のドキュメントで、GiST インデックスが一意でない複数列のインデックスをサポートしていることを確認しました。
しかし、それらの実際の違いが何であるかはわかりませんでした。私の仲間のコーダーが、それらの間の長所と短所は何か、そしてさらに重要なことに、私が一方を他方よりも使用する理由を説明できることを望んでいましたか?
私は最近、Postgres データベースの最適化に取り組んでおり、伝統的に B-Tree インデックスしか使用していません。ただし、Postgres 8.3 のドキュメントで、GiST インデックスが一意でない複数列のインデックスをサポートしていることを確認しました。
しかし、それらの実際の違いが何であるかはわかりませんでした。私の仲間のコーダーが、それらの間の長所と短所は何か、そしてさらに重要なことに、私が一方を他方よりも使用する理由を説明できることを望んでいましたか?
基本的に誰もが正しい-btreeは非常に優れたパフォーマンスを発揮するため、デフォルトのインデックスです。GiSTは多少異なる獣です。それは、それ自体のインデックスタイプというよりも、「インデックスタイプを作成するためのフレームワーク」です。それを使用するには(サーバーに)カスタムコードを追加する必要がありますが、その一方で、非常に柔軟性があります。
一般的に、使用しているデータ型から指示がない限り、GiSTは使用しません。GiSTを使用するデータ型の例:ltree(contribから)、tsvector(8.2までのcontrib / tsearch、8.3以降のコア)など。
PostgreSQLにはよく知られた非常に高速な地理的拡張があります-その目的のためにGiSTを使用するPostGIS( http://postgis.refractions.net/ )。
GiST indexes are lossy to an extent, meaning that the DBMS has to deal with false positives/negatives, i.e.:
GiST indexes are lossy because each document is represented in the index by a fixed- length signature. The signature is generated by hashing each word into a random bit in an n-bit string, with all these bits OR-ed together to produce an n-bit document signature. When two words hash to the same bit position there will be a false match. If all words in the query have matches (real or false) then the table row must be retrieved to see if the match is correct. b-trees do not have this behavior, so depending on the data being indexed, there may be some performance difference between the two.
See for text search behavior http://www.postgresql.org/docs/8.3/static/textsearch-indexes.html and http://www.postgresql.org/docs/8.3/static/indexes-types.html for a general purpose comparison.
GiST are more general indexes. You can use them for broader purposes that the ones you would use with B-Tree. Including the ability to build a B-Tree using GiST.
I.E.: you can use GiST to index on geographical points, or geographical areas, something you won't be able to do with B-Tree indexes, since the only thing that matter on a B-Tree is the key (or keys) you are indexing on.