BTREE 인걸로 압니다~~

btree는 디폴트로 걸리는 인덱스이고요 주로 숫자형이나 문자형에 걸리는 인덱스입니다.

rtree는 다차원데이터타입에 쓰이는 인덱스이고요, 주로 2차원을 가지는 데이터 타입인 point나 polygon 따위의 데이터를 저장하는 테이블에 걸리는 인덱스입니다.

hash는 hashing 방법을 이용한 인덱싱 방법입니다. hash는 트리구조를 가지지 않고 hash function을 이용하는게 특징입니다.

gist는 GeneraIzed Search Tree의 약자이고요, 개발자들을 위한 인덱스 패키지라고 생각하면 쉽습니다. contrib 폴더에 가시면 다양한 타입들을 지원하는데요... 그러한 타입들에 인덱스를 만들고 싶을때 모든 코딩을 전부 하지 않더라도 이 gist라는 놈을 이용하면 index를 비교적 쉽게 만들 수 있죠... 그래서, gist는 그 자체로는 인덱스로 보긴 어렵습니다. 하지만, gist를 이용해서 rtree on gist 혹은 btree on gist, int array on gist 등의 인덱스를 만들 수 있고, Create Index 문장에서 이렇게 구체화된 인덱스를 사용할 수 있습니다...

답변 주신 이민우님, 신기배님 정말 감사합니다. (__)

추가로 여쭈어 보겠습니다.

이문제가 나온것은 두컬럼을 primary key 로 잡는 composite 키의 경우 속도가 느리다는 얘기가 나와서 인덱스가 틀리게 잡히는 줄로 잘못알고 여쭈어 본것입니다. 다른 글에서 찾은 아래 Rank Access Path를 보면...

Rank Access Path
=====================================
1. ROWID에 의한 한 행
2 클러스터 조인에 의한 한 행
3. Unique나 Primary Key를 사용한 해쉬 클러스터에 의한 한 행
4. Unique나 Primary Key에 의한 한 행
5. 클러스터 조인
6. 해쉬 클러스터 키
7. 인덱스된 클러스터 키
8. Composite 키

이하 생략....

=======================================

여기서보면 8번으로 3,4번 보다 느립니다.

3번,4번의 차이점인 해쉬 클러스터는 어떻게 설정하는 것인지요?

그리고 위글은 Oracle 의 경우인데 PostgreSQL에선 어떤가요?

어떤 키가 있고, 그 키의 순서가 절대로 바뀌지 않고,

중간에 끼어드는 일이 없다면, 당연히 크러스트가 제일 빠르겠지요.

(개인적인 생각으로는 특정 자료의 단일 검색에 대해서는 hash 인덱스가 제일 빠를 듯싶은데, 아무튼 범위 검색이라면, 복합 btree 인덱스보다 크러스트가 바를겝니다)

PostgreSQL에서도 크러스트 방식의 인덱스 - 엄격히 말하면 인덱스라고 하기는 그렇고, 자료의 저장방식이라고 하는 것이 맞겠지요 - 를 지원하는데, 자세한 것은 아래 문서를 참조하세요.