PostgreSQL 8.3.3문서
Prev Fast Backward Chapter 33. SQL 확장 Fast Forward Next

33.14. 인덱스 확장 기능의 인터페이스

지금까지는, 새로운 형태나 새로운 함수, 및 새로운 연산자를 어떻게 정의할지에 대해서 설명해 왔습니다. 그렇지만, 새로운 형태의 열에 대한 인덱스를 아직 작성할 수가 없습니다. 이 때문에는, 새로운 데이터형에 대한 연산자 클래스를 정의해야합니다. 본절에서는, 복소수를 값의 절대값의 오름차순 정렬해 저장하는 B-tree 인덱스 방법을 사용한 새로운 연산자 클래스에 대한 실행 예를 이용해, 연산자 클래스의 개념을 설명합니다.

Note: PostgreSQL 7.3 릴리스 이전까지는, 사용자 정의된 연산 클래스를 생성하기 위해 시스템 목록pg_amop, pg_amproc, pg_opclass를 메뉴얼에 추가해야 했습니다. 이런 접근방식은 사용이 중지되었습니다. CREATE OPERATOR CLASS 가 훨씬 간단하고 에러가 적은 필요 목록 엔트리의 생성 방법이기 때문입니다.

33.14.1. 인덱스 방법와 연산자 클래스

pg_am테이블에는 각 인덱스 방법(내부에서는 접속 방법으로서 알려져 있습니다)에 대해서 1개의 행이 포함되어 있습니다. 테이블에의 보통의 접속 지원은 PostgreSQL에 내장돼있습니다만, 모든 인덱스 방법은, pg_am로 기술되고 있습니다. 필요하게 되는 인터페이스 루틴을 정의한 후, pg_am에 행을 작성하는 것에 의해, 새로운 인덱스 방법을 추가하는 것이 가능합니다. 그러나, 이 방법에 대한 설명은 본장에서의 범위를 넘고 있습니다(Chapter 49를 참조해 주세요).

인덱스 방법의 루틴에는, 직접적으로 인덱스 방법이 연산하는 데이터형의 정보는 아무것도 주어지고 있지 않습니다. 대신에, 연산자 클래스가, 특정의 데이터형의 조작에 대해 인덱스 방법을 사용할 필요가 있는 연산의 집합을 식별합니다. 연산자 클래스라는 이름의 유래는, 그것들이 지정하는 것의 1개에 인덱스로 사용할 수 있는 (즉, 인덱스 검색 조건으로 변환할 수 있다) WHERE구 연산자의 집합이 있기 때문입니다. 또, 연산자 클래스는, 인덱스 방법의 내부 연산으로 필요한, 그러나 인덱스로 사용할 수 있는 WHERE구 연산자에는 직접적으로는 대응하지 않는, 지원 프로시저를 몇개 지정할 수가 있습니다.

같은 입력 데이터형 및 인덱스 방법에 대해서 복수의 연산자 클래스를 정의하는 것이 가능합니다. 이것에 의해, 1개의 데이터형에 대해서, 인덱스부 의미론의 다수의 집합을 정의할 수 있습니다. 예를 들면, B-tree 인덱스에서는, 처리하는 데이터형 마다 정렬순서를 정의할 필요가 있습니다. 복소수 데이터형에서는, 복소수의 절대값에 의해 데이터를 정렬하는 B-tree 연산자 클래스와 실부의 수치에 의해 정렬하는 B-tree 연산자 클래스를 갖는 방법은, 유용할것입니다. 통상은 연산자 클래스의 하나가 일반적으로 가장 유용하다고 판단되어 그 데이터형 및 인덱스방법에 대한 기본값의 연산자 클래스로서 설정됩니다.

몇몇의 다른 인덱스 방법에, 동일한 연산자 클래스명을 사용할 수가 있습니다 (예를 들면, B-tree와 해시 인덱스 방법은, 둘 다 int4_ops라는 이름의 연산자 클래스를 가질 수가 있습니다). 다만, 그러한 각 클래스는 독립된 실체이며, 따로 따로 정의될 필요가 있습니다.

33.14.2. 인덱스 방법의 전략

연산자 클래스에 관련지을 수 있는 연산자는, "전략 번호"에 의해 식별됩니다. "전략 번호"는, 연산자 클래스의 문맥 내의 각 연산자의 의미론을 식별하기 위한 것입니다. 예를 들면, B-tree의 경우, 키가 작은 쪽에서 큰 쪽으로 엄격하게 줄지어 있어야합니다. 따라서, B-tree에 관해서, "보다 작고" "더 크거나" 동일한 연산자는 흥미롭습니다. PostgreSQL에서는 사용자가 연산자를 정의할 수 있기 때문에, PostgreSQL는 연산자의 이름(예를 들면 <나 >=)을 찾아내도, 그 연산자가 어떠한 비교를 실시할지 판단할 수 없습니다. 그 대신해, 인덱스 방법은 "전략"의 집합을 정의합니다. "전략"는, 범용 연산자라고 생각할 수 있습니다. 각 연산자 클래스는, 특정의 데이터형 및 인덱스 의미론의 해석에 있어, 실제의 어느 연산자가 각 전략에 대응하는지를 지정합니다.

Table 33-2에 나타나듯이, B-tree 인덱스 방법에서는 전략을 5개 정의합니다.

Table 33-2. B-tree 전략

연산 전략 번호
보다 더 작은 1
이하 2
동일하다 3
이상 4
보다 더 큰 5

해시 인덱스는, 비트마다의 등가성만을 지원합니다. 따라서, Table 33-3에 나타나듯이, 전략을 1개만 정의합니다.

Table 33-3. 해시 전략

연산 전략 번호
동일하다 1

GiST 인덱스는 더욱 유연합니다. 고정된 전략의 집합을 전혀 가지지 않습니다. 대신, 특정의 GiST 연산자 클래스의 "consistent"지원 루틴이, 전략 번호가 무엇을 의미하는지를 해석합니다. 예를 들어, 몇몇의 내장된 GiST 인덱스 연산자 클래스는, 2 차원 기하 객체를 인덱스 붙여, Table 33-4 에 보여지는 "R-tree"전략을 제공합니다. 이 중 4개는 2 차원(중복, 합동, 함유, 피함유) 테스트입니다. 나머지 8개 중 4개는 X방향에 대한, 나머지 4개는 Y방향에 대한 동일한 테스트를 제공합니다.

Table 33-4. GiST 2 차원 "R-tree"전략

연산 전략 번호
완전하게 좌측 1
우측에는 확장하지 않는다 2
겹친다 3
좌측에는 확장하지 않는다 4
완전하게 우측 5
같다 6
포함한다 7
포함된다 8
위쪽에는 확장하지 않는다 9
완전하게 아래 쪽 10
완전하게 위쪽 11
아래 쪽에는 확장하지 않는다 12

GIN 인덱스는 유연성이라는 점으로써 GiST와 닮아 있습니다. 그러나, 고정된 전략군을 가지지 않습니다. 그 대신에, 각 연산자 클래스의 지원 루틴이 연산자 클래스의 정의에 따라 전략수를 해석합니다. 예를 들면, 편입의 배열에 대한 연산자 클래스의 전략을 Table 33-5에 나타냅니다.

Table 33-5. GIN 배열의 전략

조작 전략수
중복 1
포함 2
함유 된다 3
동일하다 4

모든 전략 연산자는 논리값을 반환하는 것에 주의해 주세요. 실제, 인덱스로 사용되기 위해서 WHERE의 최상정도 레벨로 나타나야 하기 때문에, 인덱스 방법 전략으로서 정의된 모든 연산자의 반환값의 형태는 boolean가 아니면 안됩니다.

33.14.3. 인덱스 방법의 지원 루틴

전략은 통상, 시스템이 인덱스를 사용하는 방법을 판단하기 위해서(때문에) 충분한 정보가 아닙니다. 실제로는, 인덱스 방법은, 작업을 위해서(때문에) 추가의 지원 루틴을 필요로 합니다. 예를 들면 B-tree 인덱스 방법은, 2개의 키를 비교해, 보다 큰 것인지, 동일한 것인지, 보다 작은 것인지를 결정할 수 없으면 안됩니다. 같이 해시 인덱스는, 키치의 해시 코드를 계산할 수 없으면 안됩니다. 이러한 조작은 SQL 명령의 조건내에서 사용되는 연산자와는 대응하지 않습니다. 이것들은 인덱스 방법으로 내부적으로 사용되는 관리용 루틴입니다.

전략처럼, 연산자 클래스에 의해 주어진 데이터형 및 의미론 해석에 대해서, 어느 특정의 함수가 이러한 각 역할을 완수해야 하는 것인지가 식별됩니다. 인덱스 방법은 필요한 함수의 집합을 정의하고, 연산자 클래스는, 인덱스 방법으로 지정된 "지원 함수 번호"에 대입하는 것에 의해, 사용해야 할 올바른 함수를 식별합니다.

Table 33-6에 나타나듯이, B-tree에는 단일의 지원 함수가 필요합니다.

Table 33-6. B-tree 지원 함수

함수 지원 번호
2개의 키를 비교해, 첫번째 키가 2번째의 키보다 작은지, 동일한지, 큰지 나타내는, 0 미만, 0, 혹은 0보다 큰 정수를 돌려줍니다. 1

Table 33-7에 나타나듯이, 해시 인덱스도 이와 같이 단일의 지원 함수가 필요합니다.

Table 33-7. 해시 지원 함수

함수 지원 번호
키의 해시값을 계산 1

Table 33-8에 나타나듯이, GiST 인덱스에는 7개의 지원 함수가 필요합니다.

Table 33-8. GiST 지원 함수

함수 지원 번호
consistent - 키가 쿼리 조건을 채울지 어떨지를 결정합니다. 1
union - 키의 집합의 화집합을 계산합니다. 2
compress - 키 또는 인덱스 붙이고 되는 값의 압축 표현을 계산합니다. 3
decompress - 압축된 키의 압축이 풀린 표현을 계산합니다. 4
penalty - 지정된 서브트리 키를 가지는 서브트리에 새로운 키를 삽입할 때의 패널티를 계산합니다. 5
picksplit - 페이지의 어느 엔트리를 새로운 페이지에 이동시킬지를 결정해, 결과 페이지용의 통합 키를 계산합니다. 6
equal -2개의 키를 비교해, 동일하면 참을 돌려줍니다. 7

GIN 인덱스는, Table 33-9에 나타나는 4개의 지원 함수를 필요로 합니다.

Table 33-9. GIN 지원 함수

함수 지원 수
비교. 2개의 키를 비교해, 0 미만, 0, 0보다 큰 정수를 돌려줍니다. 각각 첫 번째 키가 큰지, 동일한지, 작은지를 나타냅니다. 1
값추출. 인덱스 붙인 값으로부터 키를 추출합니다. 2
쿼리 추출. 쿼리 조건으로부터 키를 추출합니다. 3
일관성. 뭐리 조건에 일치하는 값인지 아닌지를 결정합니다. 4

전략 연산과 달리, 지원 함수는 특정의 인덱스 방법이 상정하는 데이터형, 예를 들면 B-tree용의 비교 함수의 경우, 부호 첨부 정수를 돌려줍니다.

33.14.4. 예

여기까지로 개념에 대해 설명해 왔습니다. 여기서, 새로운 연산자 클래스를 작성하는 유용한 예를 소개합니다 (이 예를 작업할 수 있도록, 배포된 소스내에 src/tutorial/complex.c와 src/tutorial/complex.sql에 복사가 있습니다). 이 연산자 클래스는, 복소수를 그 절대치에 의한 차례로 소트 하는 연산자를 캡슐화합니다. 그러므로, 그 이름에 complex_abs_ops를 선택했습니다. 첫 번째로, 연산자의 집합이 필요하게 됩니다. 연산자를 정의하는 처리는 Section 33.12으로 설명했습니다. B-tree상의 연산자 클래스에서는, 이하의 연산자가 필요합니다.

비교 연산자의 관련하는 집합을 정의할 때에 에러의 발생을 최소로 하는 방법은, 우선, B-tree 비교 지원 함수를 작성해, 그 후에, 다른 함수를 지원 함수에 대한 하나의 행의 덮개로서 작성하는 것입니다. 이것에 의해, 찬합의 구석에서 일관성이 없는 결과를 얻는 확률이 감소합니다. 이 접근법에 따라, 우선 이하를 작성합니다. 

#define Mag(c)  ((c)->x*(c)->x + (c)->y*(c)->y)

static int
complex_abs_cmp_internal(Complex *a, Complex *b)
{
    double      amag = Mag(a),
                bmag = Mag(b);

    if (amag < bmag)
        return -1;
    if (amag > bmag)
        return 1;
    return 0;
}

이것으로, 더 작은 함수는 이하와 같이 됩니다. 

PG_FUNCTION_INFO_V1(complex_abs_lt);

Datum
complex_abs_lt(PG_FUNCTION_ARGS)
{
    Complex    *a = (Complex *) PG_GETARG_POINTER(0);
    Complex    *b = (Complex *) PG_GETARG_POINTER(1);

    PG_RETURN_BOOL(complex_abs_cmp_internal(a, b) < 0);
}

다른 네 개의 함수에서의 차이는, 내부 함수의 결과와 0을 어떻게 비교하는가 입니다.

다음에, 함수와 이 함수에 근거하는 연산자를 SQL로 선언합니다. 

CREATE FUNCTION complex_abs_lt(complex, complex) RETURNS bool
    AS '
filename
', 'complex_abs_lt'
    LANGUAGE C IMMUTABLE STRICT;

CREATE OPERATOR < (
   leftarg = complex, rightarg = complex, procedure = complex_abs_lt,
   commutator = > , negator = >= ,
   restrict = scalarltsel, join = scalarltjoinsel
);

올바르게 교환 연산자와 부정자 연산자를 지정하는 것 외에도, 적절한 제한 선택성 함수와 결합 함수를 지정하는 것이 중요합니다. 그렇지 않으면, 최적화는 인덱스를 효율적으로 사용할 수가 없습니다. 더 작거나, 동일하거나, 더 큰 경우에 다른 선택성 함수를 사용해야 하는 것에 주의해 주세요.

그 밖에도, 값이 없는 것이 여기서 발생합니다.

다음의 스텝은, B-tree에 필요한 지원 루틴의 등록입니다. 이것을 구현하는 C코드는, 연산자 함수와 같은 파일에 들어있습니다. 이하는, 함수를 어떻게 선언하는지를 나타냅니다. 

CREATE FUNCTION complex_abs_cmp(complex, complex)
    RETURNS integer
    AS '
filename
'
    LANGUAGE C IMMUTABLE STRICT;

지금까지로, 필요한 연산자 및 지원 루틴을 가지게 되었습니다. 마지막에 연산자 클래스를 작성할 수가 있습니다. 

CREATE OPERATOR CLASS complex_abs_ops
    DEFAULT FOR TYPE complex USING btree AS
        OPERATOR        1       < ,
        OPERATOR        2       <= ,
        OPERATOR        3       = ,
        OPERATOR        4       >= ,
        OPERATOR        5       > ,
        FUNCTION        1       complex_abs_cmp(complex, complex);

이것으로 마지막입니다! 이것으로 complex열에 B-tree 인덱스를 만들어 사용하는 것이 가능하게 되었을 것입니다.

이하와 같이, 연산자 엔트리를 보다 장황하게 기술할 수 있습니다. 

        OPERATOR        1       < (complex, complex) ,

그러나, 연산자가, 연산자 클래스의 정의와 동일한 데이터형인 경우, 이러한 기술을 할 필요는 없습니다.

상기의 예는, 사용자가 이 새로운 연산자 클래스를 complex데이터형의 기본값의 B-tree 연산자 클래스로 하려는 것을 가정하고 있습니다. 이와 같이 하지 않는 경우, DEFAULT라고 하는 단어를 없애 주세요.

33.14.5. 교차 데이터형 연산자 클래스

지금까지는 암묵적으로, 연산자 클래스는 1개의 데이터형만을 취급하는 것을 가정해 왔습니다. 확실하게 특정의 인덱스열에 단 1개의 데이터형만 있지만, 다른 데이터형의 값과 인덱스열의 비교를 실시하는 인덱스 조작은 자주 도움이 됩니다. 또, 연산자 클래스와 관련한 데이터형을 걸치는 연산자를 사용할 수 있는 경우, 다른 데이터형은 독자적인 관련한 연산자 클래스를 가지는 일이 자주 있습니다. 이것은 곧 B-tree와 GiST 인덱스 메소드에 의해 지원됩니다.

B-트리는 각 연산자의 왼쪽 오퍼랜드가 인데스된 데이터형이어야 하지만, 오른쪽 오퍼랜드는 다른형일 수 있습니다. 

CREATE OPERATOR CLASS int8_ops
DEFAULT FOR TYPE int8 USING btree AS
  -- standard int8 comparisons
  OPERATOR 1 < ,
  OPERATOR 2 <= ,
  OPERATOR 3 = ,
  OPERATOR 4 >= ,
  OPERATOR 5 > ,
  FUNCTION 1 btint8cmp(int8, int8) ,

  -- cross-type comparisons to int2 (smallint)
  OPERATOR 1 < (int8, int2) ,
  OPERATOR 2 <= (int8, int2) ,
  OPERATOR 3 = (int8, int2) ,
  OPERATOR 4 >= (int8, int2) ,
  OPERATOR 5 > (int8, int2) ,
  FUNCTION 1 btint82cmp(int8, int2) ,

  -- cross-type comparisons to int4 (integer)
  OPERATOR 1 < (int8, int4) ,
  OPERATOR 2 <= (int8, int4) ,
  OPERATOR 3 = (int8, int4) ,
  OPERATOR 4 >= (int8, int4) ,
  OPERATOR 5 > (int8, int4) ,
  FUNCTION 1 btint84cmp(int8, int4) ;

이 정의는 연산자 전략 함수 번호와 지원 함수 번호를 "덧쓰기"하는 것에 주의해 주세요. 특정 번호의 인스턴스가 각각 다른 오른쪽 입력 데이터형을 가지는 한, 이것은 허용됩니다. 크로스형이 아닌 인자는 연산자클래스의 기본값이거나 주 연산자입니다.

GiST 인덱스는 전략 오버로딩이나 지원 기능 수를 허용하지 않습니다만, 지원이 필요한 각 연산자에 전략 수를 할당함으로써, 지원하는 복수의 오른쪽 데이터형의 효과를 가지는 것이 가능합니다. 계속적 지원 함수는 어떤 전략수에 따라 필요한 것을 결정하고, 적절한 데이터형의 비교값을 받아들일 준비가 되어야 합니다.

33.14.6. 시스템의 연산자 클래스에 대한 의존성

PostgreSQL는 연산자 클래스를, 단지 인덱스로 사용할 수 있을지 없을지 만이 아니고, 많은 방식에서 연산자의 성질을 추정하기 위해서 사용합니다. 따라서, 데이터형의 열을 인덱스 붙일 생각이 없어도, 연산자 클래스를 작성하는 것이 좋을 가능성이 있습니다.

구체적으로, ORDER BY나 DISTINCT 등, 값의 비교와 정렬을 필요로 하는 SQL 기능이 있습니다. 사용자 정의의 데이터형에 대해서 이 기능을 구현하기 위해서, PostgreSQL는 그 데이터형용의 기본값의 B-tree 연산자 클래스를 검색합니다. 이 연산자 클래스의 "동일한" 구성원이, GROUP BY나 DISTINCT용 값의 등가성에 대한 시스템의 개념을 정의해, 이 연산자 클래스에 의해 강제당하는 정렬순서가, 기본값의 ORDER BY순서를 정의합니다.

또, 사용자 정의형의 배열의 비교는, 기본값의 B-tree 연산자 클래스에 의해 정의되는 의미론에 의존합니다.

데이터형용의 기본값의 B-tree 연산자 클래스가 존재하지 않으면 시스템은 기본값의 해시 연산자 클래스를 검색합니다. 그러나, 이 종류의 연산자 클래스는 등가성만을 제공하기 때문에, 실제로 이것은, 배열 등가성을 지원하기에 충분합니다.

데이터형용의 기본값의 연산자 클래스가 존재하지 않는 경우에, 이러한 SQL 기능을 데이터형에 사용하려고 하면, "연산자 클래스를 식별할 수 없었다"는 에러가 됩니다.

Note: PostgreSQL버전 7.4보다 전까지에서는, 정렬이나 그룹화 조작은 암묵적으로 =, <, >라는 이름의 연산자를 사용하고 있었습니다. 이 새로운, 기본값의 연산자 클래스에 의존하는 행동에 의해, 특정 이름을 가지는 연산자의 행동에 대해 어떠한 가정을 세우는 것을 방지하고 있습니다.

33.14.7. 연산자 클래스의 특수한 기능

연산자 클래스에는, 아직 설명하지 않은 2 개의 특수한 기능이 있습니다. 설명하지 않은 주된 이유는, 가장 자주 사용하는 인덱스 방법에서는, 그다지 유용하지 않기 때문입니다.

통상, 연산자를 연산자 클래스의 멤버로서 선언하면, 인덱스 방법으로 그 연산자를 사용해, WHERE조건을 채우는 행의 집합을 정확하게 추출할 수가 있습니다. 이하에 예를 나타냅니다. 

SELECT * FROM table WHERE integer_column < 4;

이 식은, 정수열에 B-tree 인덱스를 사용해 정확하게 채울 수 있습니다. 그러나, 일치하는 행에 일치하지 않더라도 이끄는 수단으로서 인덱스가 유용한 경우가 있습니다. 예를 들면, GiST 인덱스로, 객체의 경계 박스만을 저장합니다. 그 결과, 다각형과 같은 직사각형이 아닌 객체와 중복인지 테스트하는 WHERE 조건은 정확하게 채울 수가 없습니다. 무엇보다, 이 인덱스를 사용해, 대상 객체의 경계 박스와 중복되는 경계 박스를 가지는 객체를 검색하고, 뿐만 아니라, 검색된 객체에 대해서만 정확하게 겹칠지 아닐지를 테스트할 수 있습니다. 이러한 경우, 인덱스는, 연산자에 대해 "손실이 많은" 것이 됩니다. 거기서, CREATE OPERATOR CLASS명령의 OPERATOR구에, RECHECK를 추가합니다. RECHECK는, 인덱스가, 모든 필요한 행, 및 몇 개의 추가의 행의 반환을 보증한 경우에 유효합니다. 이 추가의 행은, 원래의 연산자 호출을 실행하는 것에 의해 제거할 수 있습니다.

다각형과 같이 복잡한 객체의 경계 박스만을 인덱스에 저장하는 상황을 생각해 보세요. 이 경우, 인덱스 엔트리에 다각형 전체를 저장하는 것은, 그만큼 유용한 일이 아닙니다. 단지, 보다 단순한 box형의 객체를 저장하는 것이 좋을지도 모릅니다. 이러한 상황은, CREATE OPERATOR CLASS의 STORAGE옵션에 의해 표현할 수 있습니다. 예를 들면, 이하와 같이 기술합니다. 

CREATE OPERATOR CLASS polygon_ops
    DEFAULT FOR TYPE polygon USING gist AS
        ...
        STORAGE box;

현재, GiST 인덱스 방법과 GIN 인덱스 방법이, 열의 데이터형과 다른 STORAGE형을 지원하고 있습니다. STORAGE가 사용되었을 경우, GiST의 compress 및 decompress지원 루틴은, 데이터형을 변환할 필요가 있습니다. GIN에서는, STORAGE형은 "키"의 값의 형태를 식별합니다. 통상, 이것은 인덱스 붙인 열의 형태와는 다릅니다. 예를 들면, 정수 배열의 렬용의 연산자 클래스는 같은 정수를 키로서 가질지도 모릅니다. extractValue및extractQuery지원 루틴이, 인덱스 붙인 값으로부터 키를 꺼낼 책임을 가집니다.

Prev Home Next
연산자 최적화에 관한 정보 Up 트리거