postgresql 인덱스 문자열에

Question

말해, ResidentInfo 테이블이 있고이 테이블에서 VARCHAR 유형입니다 고유 한 제약이 있습니다. 장래의 쿼리에서는,이 열에 인덱스를 추가 할 예정입니다. 쿼리는 오직 =의 연산만을 가질 것이고, 해쉬 패턴은 현재 권장되지 않기 때문에 B-TREE 패턴을 사용할 것입니다.

질문 : 효율성보기에서 B-TREE를 사용하여 숫자 1,2,3 .... N이 다른 홈 주소에 해당하는 새 열을 추가해야한다고 생각하십니까? HomeAddress에 색인을 추가하는 대신, 번호 열에 색인을 추가해야합니까?

인덱스 작동 방식을 모르므로이 질문을합니다.

Answer 1

단순 균등 검사 (=)의 경우 varchar 또는 text 열의 B- 트리 색인은 간단하고 최선의 선택입니다. 그것은 확실히 성능을 돕는다 많이.

물론 B-Tree 인덱스가 단순한 integer 일 때 더 좋습니다. 우선 간단한 integer 값을 비교하는 것이 약간 빠릅니다. 그러나 더 중요한 것은 성능은 인덱스 크기의 함수이기도합니다. 큰 열은 데이터 페이지 당 더 적은 행을 의미하므로 더 많은 페이지를 읽어야합니다. ...

어쨌든 HomeAddress은 고유하지 않으므로 자연스러운 기본 키가 아닙니다. 대체로 대리 우선 키을 대신 사용하는 것이 좋습니다. A serial column은이를위한 확실한 선택입니다. 그 유일한 목적은 작업 할 수있는 간단하고 빠른 기본 키를 갖는 것입니다.

상기 테이블을 참조하는 다른 테이블이있는 경우 더욱 효율적입니다. 외래 키 열에 긴 문자열을 복제하는 대신 정수 열에 대해 4 바이트 만 필요합니다. 그리고 주소를 변경해야하기 때문에 업데이트를 너무 많이 캐스케이드 할 필요가 없으며 서로 게이트가 동일하게 유지 될 수 있습니다 (물론 필요하지는 않음).

테이블은 다음과 같이 수 :

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

CREATE INDEX resident_adr_idx ON resident(address); 

이 두 개의 B-tree 인덱스가 발생합니다. 고유 한 인덱스는 resident_id이고 일반 인덱스는 address입니다.

More about indexes in the manual.
Postgres는 많은 옵션을 제공하지만이 간단한 경우에는 더 이상 필요하지 않습니다.

Answer 2

Postgres에서 고유 제약 조건은 필드에 고유 색인을 유지함으로써 시행되므로 이미 다루어집니다. 당신이 주소를 고유 제한 조건을 결정하는 경우에

는 (솔직히,이 인? : 별도의 계정을 만드는 것을 배우자 flatshares에 대해 등?) 나쁜, 당신이 그렇게 좋아 하나 만들 수 있습니다

을

create index on ResidentInfo (HomeAddress);