postgresqlインデックスの文字列

Question

と言って、私はテーブルResidentInfoを持っています。このテーブルには、VARCHARタイプの固有の制約HomeAddressがあります。将来のクエリでは、この列にインデックスを追加します。 クエリには操作=しかありません。ハッシュパターンは現在推奨されていないため、B-TREEパターンを使用します。

質問：B-TREEを使用する効率的な見方からは、異なるhomeaddressに対応する数字1,2,3、... Nの新しい列を追加し、HomeAddressにインデックスを追加する代わりに、私は数値の列にインデックスを追加する必要がありますか？

私はインデックスの仕組みがわからないので、この質問をします。

Answer 1

単純な等価チェック（=）の場合、varcharまたはtext列のBツリーインデックスはシンプルで最適な選択です。それは確かにパフォーマンスを助ける多くの。

もちろん、単純なBツリーインデックスintegerが優れています。まず、単純なintegerの値を比較するのは少し速いです。しかし、パフォーマンスはインデックスのサイズの関数でもあります。大きな列はデータページあたりの行数が少ないことを意味します。

HomeAddressはほとんどの場合ユニークではないため、自然なプライマリキーではありません。代わりに代理プライマリキーを使用することを強くお勧めします。そのためにはserial columnが明らかです。その唯一の目的は、操作が簡単で高速な主キーを持つことです。

上記のテーブルを参照する他のテーブルがある場合は、これがさらに効率的になります。外部キー列に長い文字列を複製するのではなく、整数列の4バイトのみが必要です。アドレスが変更に拘束されているため、サロゲートpkは同じままにすることができます（しかし、もちろんそうする必要はありません）ので、更新をあまりカスケードする必要はありません。

あなたのテーブルには、次のようになります。

CREATE TABLE resident (
    resident_id serial PRIMARY KEY 
    ,address text NOT NULL 
    -- more columns 
); 

CREATE INDEX resident_adr_idx ON resident(address); 

これは、2つのBツリー・インデックスになります。ユニークなインデックスはresident_idで、プレーンインデックスはaddressです。

。
Postgresには多くのオプションがありますが、この単純なケースではもう必要ありません。

Answer 2

Postgresでは、ユニークな制約がフィールドにユニークなインデックスを維持することで強制されるため、すでにカバーされています。あなたはアドレスに一意制約を決定した場合には

は（？正直、それはある、：配偶者が別々のアカウントを作成するものflatsharesについてなど）悪い：

、あなたはそうのようなものを作成することができます

create index on ResidentInfo (HomeAddress);