| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 11. 인덱스 | Fast Forward | Next |
PostgreSQL에서는 인덱스의 보수나 튜닝은 필요 없지만, 어느 인덱스가 실제의 쿼리로 사용되고 있는지 확인하는 것은 역시 중요합니다. 개개의 커맨드에서의 인덱스의 사용 상황은 EXPLAIN 커맨드로 검증할 수 있습니다. 이 목적을 위한 용례를Section 13.1에 나타냅니다. 또한, Section 25.2에 나타내는 대로, 가동중의 서버서 인덱스 사용 상황의 전체적인 통계 정보를 꺼낼 수도 있습니다.
어느 인덱스를 설정해야할 것인가를 판단하기 위한 일반적인 순서를 정하는 것은 곤란합니다. 지금까지는 예로서 전형적인 케이스를 몇 개인가 기술해 왔습니다. 많은 경우, 충분한 검증이 필요합니다. 본 절의 나머지는 검증을 위한 힌트 몇 개를 설명하겠습니다.
우선, 반드시 ANALYZE 커맨드를 실행해 주십시요. 이 커맨드에 의해, 테이블 내의 값의 분포에 관한 통계 정보를 수집합니다. 이 정보는 쿼리에 의해 돌려주어지는 행 수를 추측할 때 필요합니다. 추측된 행 수는 가능한 계획에 실질적인 코스트를 할당하기 위해서 planner가 필요합니다. 실제의 통계 정보가 조금이라도 비어 있는 경우, 디폴트 값이 가정됩니다. 이 디폴트 값은 거의 부정확합니다. 따라서, ANALYZE커맨드를 실행하지 않고 , 어플리케이션의 인덱스 사용 상황을 검증해도, 그다지 의미가 없습니다.
검증에는 실제로 사용하는 데이터를 사용해 주십시요. 테스트 데이터를 사용해 인덱스를 작성했을 경우, 테스트 데이터에 필요한 인덱스 알지만, 그 이상은 모릅니다.
매우 작은 테스트 데이터를 사용하는 일도, 결과에 특히 치명적인 영향을 줍니다. 100,000행에서 1,000 행을 선택하는 경우는 인덱스가 사용될 가능성이 있지만, 100 행에서 1행을 선택하는 경우는 인덱스가 우선적으로 사용되지 않습니다. 왜냐하면, 100행은 아마 1개의 디스크 페이지에 들어가기 때문에, 1 페이지를 순서대로 읽어내는 것보다 빠른 계획이 존재하지 않기 때문입니다.
또한, 어플리케이션이 아직 실행되지 않는 경우, 테스트 데이터를 작성 할 때는 주의가 필요합니다. 매우 유사한 값이나, 완전하게 랜덤인 값, 또는 정렬(sorting)된 순서로 값이 삽입되고 있는 경우, 그 통계 정보는 실제의 데이터의 분포와 동떨어진 것이 되어 버립니다.
인덱스가 사용되지 않은 경우, 테스트를 위해서 인덱스를 강제적으로 사용하도록 하면 편리합니다. 다양한 계획 타입을 무효로 설정할 수 있는 실행시 파라미터가 있습니다 (Section 17.6.1를 참조해 주십시요). 예를 들면, 가장 기본적인 계획인 시퀀셜 스캔(enable_seqscan) 및 nested-loop 조인(enable_nestloop)을 무효로 설정하면, 시스템은 다른 계획을 사용하도록 강요당합니다. 그러한 설정을 실시해도, 시스템이 시퀀셜 스캔이나 nested-loop 조인을 선택하는 경우, 인덱스를 사용하지 않는 이유로 좀 더 근본적인 이유가 있을 수 있습니다. 예를 들면, 쿼리의 조건이 인덱스에 일치하지 않는 것을 생각할 수 있습니다. (어떤 종류의 쿼리가 어떤 인덱스를 사용할 수 있을지는 전 장에서 설명되었습니다.)
강제적으로 인덱스를 사용하도록 설정해, 인덱스를 사용하는 경우는 다음의 2개의 상황이 생각됩니다. 시스템의 판단이 올바르고, 인덱스 사용이 실제 적절하지 않은 상황이거나 쿼리 계획의 코스트 추정이 현실을 반영하지 않는 상황입니다. 따라서, 인덱스를 사용한 쿼리의 실행 시간과 사용하지 않는 경우의 실행 시간을 측정해 볼 필요가 있습니다. 이 경우, EXPLAIN ANALYZE커맨드가 편리합니다.
코스트 추정이 잘못된 것으로 판명되었을 경우, 두 가지 가능성이 있습니다. 총 코스트는 각 계획 노드의 행 단위의 코스트에, 계획 노드의 추정 선택도를 거는 것으로 산출됩니다. 계획 노드의 코스트 추정은 실행시 파라미터에 의해 설정할 수 있습니다 (Section 17.6.2를 참조해 주십시요). 부정확한 선택도 추정은 불충분한 통계 정보의 원인이 됩니다. 통계 정보수집용의 파라미터를 조절하여 상황을 개선할 수 있습니다 ( ALTER TABLE 를 참조해 주십시요).
코스트를 적절히 조절할 수 없는 경우, 명시적으로 인덱스를 사용할 필요가 있습니다. 또는 PostgreSQL개발자에게 문제를 조사하도록 의뢰하게 될지도 모릅니다.