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

11.1. 서문

Suppose we have a table similar to this: --> 다음과 같은 테이블을 생각해 봅시다.

CREATE TABLE test1 (
    id integer,
    content varchar
);

어플리케이션은 다음과 같은 많은 쿼리 형태를 필요로 하고 있습니다.

SELECT content FROM test1 WHERE id = 
constant
;

만반의 준비를 하지 않으면, 시스템은 행마다 일치하는 모든 항목을 찾기 위해test1테이블의 항목을 스캔해야할 것입니다. 만약 test1에 많은 행이 있고 쿼리와 같이 반환될 소수의 행(아마도 0이나 1)이 있다면, 이것은 분명히 효율이 나쁜 방법이라고 할 수 있겠습니다. 그러나 시스템이 인덱스를 id열에서 유지하도록 지시하면, 일치하는 행을 발견하는 보다 효율이 좋은 방법을 사용할 수 있습니다. 예를 들면, 검색 트리의 일부 단계만을 검색해서 끝날 수 있습니다..

대부분의 논픽션에는 같은 수법이 사용되고 있습니다. 독자가 빈번하게 조사하는 용어 및 개념은 책 마지막에 알파벳 순서에 따른 색인으로 정리하고 있습니다. 이 책에 흥미를 가진 독자는 색인(인덱스)을 통해 비교적 빠르고 간단하게 해당 페이지를 볼 수 있으므로, 보고 싶은 부분을 찾기 위해서 전부를 읽지 않아도 됩니다. 독자가 빈번히 조사할만한 항목을 예상하는 것이 저자의 일이듯, 어느 인덱스가 유익한가를 예측하는 것은 데이터베이스 프로그래머의 일입니다.

위에서 설명한 바와 같이id열에 인덱스를 작성하는 경우는 이하와 같은 커맨드를 사용합니다.

CREATE INDEX test1_id_index ON test1 (id);

test1_id_index 인덱스명으로 자유롭게 선택할 수 있습니다. 그러나 무엇을 위해 인덱스를 작성했는가를 다음에 떠올릴 수 있을 만한 이름을 선택해야 합니다.

인덱스를 삭제하려면 DROP INDEX커맨드를 사용합니다. 테이블의 인덱스는 언제라도 추가 및 삭제할 수 있습니다.

일단 인덱스를 작성하면, 더 이상의 처리는 필요하지 않습니다. 시스템은 테이블이 갱신될 때 인덱스를 업데이트합니다. 또한, 쿼리에서 테이블의 시퀀셜 스캔보다 효율적이라고 판단될 경우, 인덱스를 사용합니다. 그러나 쿼리 planner로 정보에 근거한 판단을 하기 위해서는 정기적으로ANALYZE커맨드를 실행해, 통계 정보를 업데이트해야 합니다. 인덱스의 사용 여부와 planner가 인덱스를 사용하지 않겠다 라고 판단한 상황 및 이유를 조사하는 방법에 대해서는 Chapter 13을 참조해 주십시요.

인덱스는 UPDATE나 DELETE커맨드의 검색 조건에서도 사용할 수 있습니다. 대게 인덱스는 조인 검색에서 많이 사용됩니다. 따라서, 조인 조건으로 기술되는 열에 인덱스를 정의하면, 조인을 수반한 쿼리에 걸리는 시간을 꽤 단축할 수 있습니다.

대규모 테이블에 대한 인덱스 작성은 오랜 시간이 걸릴 수 있습니다. 디폴트 PostgreSQL는 인덱스 작성과 병행해 테이블을 읽어(SELECT) 낼 수 있지만, 입력(INSERT, UPDATE, DELETE)은 인덱스 작성이 끝날 때까지 금지됩니다. 이것은 종종 운용 환경에서 받아들여지지 않습니다. 인덱스 작성과 병행해 입력하는 것은 가능하지만, 몇 가지 주의해야 할 사항이 있습니다. Building Indexes Concurrently 의 정보를 참조해 주십시요.

인덱스가 작성된 후, 시스템에서는 테이블과 인덱스와의 사이에 동기화를 유지해 두어야만 합니다. 이는 데이터 조작 연산에 오버헤드를 추가시킵니다. 따라서, 드물게 혹은 전혀 사용되지 않는 쿼리 내의 인덱스는 삭제해야만 합니다.