PostgreSQL 8.3.3문서
Prev	Fast Backward	Chapter 11. 인덱스	Fast Forward	Next

11.4. 다수의 인덱스 조합

단일의 인덱스 스캔은 인덱스의 열을 연산자 클래스의 연산자로 사용하는 쿼리 조건과 그것을 AND 와 조인한 것에서만 사용합니다. 예를 들면, (a, b)의 지정된 인덱스와 WHERE a = 5 AND b = 6와 같은 쿼리 조건에서는 인덱스를 사용할 수 있습니다. 그러나 WHERE a = 5 OR b = 6과 같은 쿼리에서는 인덱스는 직접 사용되지 않습니다.

릴리스 8.1으로부터, PostgreSQL는 단일의 인덱스 스캔에서 실행할 수 없는 경우를 다루기 위해서, 다수의 인덱스(같은 인덱스를 여러번 사용하는 것을 포함)를 조합하는 기능을 가집니다. 시스템은 다수의 인덱스 스캔과 조건의AND 또는 OR를 형성합니다. 예를 들면, WHERE x = 42 OR x = 47 OR x = 53 OR x = 99와 같은 쿼리는 쿼리 구문의 하나를 사용해x상의 인덱스를 스캔 하는 4개의 스캔에 분할할 수 있습니다. 그 후, 이러한 스캔의 결과는 OR연산으로 정리해 결과를 생성합니다. 다른 예로서x와 y에 별개의 인덱스가 있는 경우를 생각합니다. WHERE x = 5 AND y = 6과 같이 쿼리에서 취할 수 있는 실행은 적절한 쿼리구로 각 인덱스를 사용해, 인덱스의 결과를 AND로 정리해 결과행을 식별하는 것입니다.

다수의 인덱스를 조합하기 위해서, 시스템은 필요한 인덱스 각각을 스캔 해, 인덱스 조건에 일치하는 것이라고 보고된 테이블행의 위치를 주기 위해서 메모리상에비트 맵을 준비합니다. 그 후, 이 비트 맵은 쿼리로 필요하게 된 것처럼, AND 또는 OR연산됩니다. 마지막으로, 실제의 테이블행이 액세스 되어 돌려주어집니다. 테이블행은 물리적인 차례로 액세스 됩니다. 비트 맵에 이 차례로 저장되고 있기 때문입니다. 이는 원래 인덱스의 순서가 없어지고 있는 것을 의미합니다. 그 때문에, 만약 쿼리가ORDER BY 구문을 가지는 경우, 이 다른 정렬(sorting) 수속이 필요합니다. 이러한 이유와 추가되는 각각의 인덱스 스캔에 불필요한 시간이 더해지는 것으로부터, planner는 추가된 인덱스를 사용할 수 있더라도, 단순한 인덱스 스캔을 선택하는 일이 있습니다.

모든 단순하지 않은 어플리케이션에서는 인덱스의 조합이 유용할 수 있습니다. 그리고 데이터베이스 개발자는 어떠한 인덱스를 제공할까를 결정하기 위해서 trade-off를 실시해야만 합니다. 다중 열 인덱스가 최선인 경우가 있고, 다른 인덱스를 작성해, 인덱스의 조합 기능에 의존하는 편이 우수한 경우도 있습니다. 예를 들면, 작업에x열만을 포함한 경우와 y열만을 포함한 경우, 양쪽 모두의 열을 포함한 경우가 혼재하는 쿼리가 포함되는 경우, x와 y에 대해, 별도의 2개 인덱스를 작성해, 양쪽의 열을 사용하는 쿼리를 처리할 때 인덱스의 조합에 의존하는 것을 선택할 수 있습니다. 또한, (x, y)에 대한 다중 열 인덱스를 작성할 수도 있습니다. 양쪽 열을 포함한 쿼리에서는 보통 이 인덱스가 인덱스의 조합보다 효율적입니다. 그러나 Section 11.3그리고 설명한 대로, y만을 포함한 쿼리에서는 거의 의미가 없습니다. 그러므로, 이 인덱스만으로 할 수 없습니다. 다중 열 인덱스의 조합이나 y에 대한 다른 인덱스가 합리적으로 제공합니다. x만을 포함한 쿼리에서는 다중 열 인덱스를 사용할 수 있습니다. 그러나 이것은 보다 커지기 때문에, x 마져 인덱스보다 저속이 됩니다. 마지막 대안 방법은 3개의 인덱스 모두 작성하는 것입니다. 그러나 이것은 아마, 테이블의 검색 빈도가 업데이트 빈도보다 높고, 3 종류의 쿼리 모두가 자주 사용되는 경우만 합리적입니다. 쿼리 안의 1개의 빈도가 다른 것보다 적으면, 자주 사용되는 종류에 일치하도록 2개의 인덱스를 작성하는 것이 좋을 것입니다.