| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 33. SQL 확장 | Fast Forward | Next |
PostgreSQL의 연산자 정의에서는, 연산자의 동작에 대한 시스템의 유용한 것들을 말해, 여러 옵션구을 포함시킬 수있습니다. 이러한 구에 의해 연산자를 사용하는 쿼리의 실행 속도가 꽤 향상하기 때문에, 이러한 구는 적절한 때에는 항상 제공되어야 합니다. 그러나, 제공할 때에는 그것들이 올바른지 확인해야 합니다! 잘못된 최적화용 구를 사용하면, 쿼리의 저속화, 알 수 없는 이상한 출력, 그 외의 유해한 일이 일어날 수 있습니다. 최적화용의 구에 대해 모르면, 사용하지 않아도 상관없습니다. 필요로 하는 것보다 쿼리의 실행이 늦어질지도 모른다고 할 뿐입니다.
PostgreSQL의 향후의 버젼에 최적화 구가 한층 더 추가될 가능성이 있습니다. 여기서 설명하는 것은 모두, 버젼8.3.3로 유효한 것입니다.
COMMUTATOR구가 주어졌을 경우, 그것은 정의된 연산자의 교환자가 되는 연산자의 이름입니다. 취할 수 있는 모든 입력값 x, y에 대해서, (x A y)가(y B x)와 동일할 때, 연산자 A는 연산자 B의 교환자라고 합니다. 또, B는 A의 교환자가 되는 것에도 주의해 주세요. 예를 들면, 통상, 특정의 데이터형의 연산자 <와 >는 서로의 교환자가 됩니다. 또, 연산자 +는 자신이 교환자가 됩니다. 그러나, 연산자 -는 교환자를 갖지 않습니다.
교대 가능한 연산자의 왼쪽 오퍼랜드의 형태는, 그 교환자의 오른쪽 오퍼랜드의 형태와 동일해, 그 반대도 또한 같습니다. 따라서,PostgreSQL로 교환자를 검색할 때에 필요한 것은 교환자의 이름이기 때문에, COMMUTATOR구에 교환자의 이름만 제공하면 충분합니다.
인덱스나 결합구로 사용되는 연산자에 대해서는 교환자의 정보를 제공하는 것이 필수입니다. 이것에 의해, 쿼리 최적화가 그 구를 다른 실행 계획형에 필요한 형식으로 "뒤집는"일이 생기기 때문입니다. 예를 들면, tab1.x = tab2.y와 같은 WHERE구를 가진 쿼리를 생각해 보겠습니다. 여기서 tab1.x와 tab2.y는 사용자 정의형으로, tab2.y에는 인덱스가 붙어 있다고 가정합니다. 최적화는, 이 구를 tab2.y = tab1.x라고 하는 형태에 뒤집는 방법을 모르면, 인덱스 검색을 생성할 수 없습니다. 인덱스 검색 기구는 연산자의 좌측으로 인덱스 된 열이 있다는 것을 상정하고 있기 때문입니다. PostgreSQL는 간단하게 이 변형이 유효하다고 전제 하지 않습니다 . =연산자의 작성자가, 교환자 정보를 가지는 연산자라고 표시해 유효함을 지정해줘야 합니다.
자기 교환자를 정의하는 경우는, 단지 그것을 지정할 뿐입니다. 교환자의 쌍을 정의하는 경우는 조금 복잡해 집니다. 하나가 정의되기 위해 다른 하나를 참조하는 것을 어떻게 할 수 있겠는지가 문제가 됩니다. 이 문제에는 아래와 같은 2개의 해결 방법이 있습니다.
1번째의 방법은, 최초의 연산자를 정의할 때에 COMMUTATOR구를 생략 해, 2번째의 연산자의 정의에서는, COMMUTATOR구에 최초의 연산자를 주는 방법입니다. PostgreSQL는 교환자가 쌍이 되어 있는 것을 알 수 있고 있기 때문에, 2번째의 정의를 보게되면, 자동적으로 최초의 정의로 돌아와 그 미정도리 되어 있는 COMMUTATOR구를 설정합니다.
다른 1개의 방법은, 양쪽 모두의 정의에 COMMUTATOR구를 포함한다는 좀 더 직선적인 방법입니다. PostgreSQL는 최초인 정의를 처리할 때에, COMMUTATOR가 존재하지 않는 연산자를 참조하고 있는 것을 알게 되면, 시스템은 그 연산자용의 가짜 엔트리를 시스템 목록에 작성합니다. 이 가짜 엔트리에는, PostgreSQL가 이 시점에 추정할 수 있는, 연산자명, 왼쪽 오퍼랜드의 형태, 오른쪽 오퍼랜드의 형태, 및 결과의 형태에 대한 보고의 유효한 데이터가 들어갑니다. 최초의 연산자의 목록 엔트리는 이 가짜 엔트리에 결부됩니다. 이 후, 2번째의 연산자가 정의되면, 시스템은 그 가짜 엔트리에 2번째 정의로부터 얻을 수 있는 추가 정보를 갱신합니다. 갱신되기 전에 가짜 연산자를 사용하면, 에러 메세지가 출력됩니다.
NEGATOR구가 주어졌을 경우, 그것은 정의하는 연산자의 부정자가 되는 연산자의 이름입니다. 입력값, x와 y가 취할 수 있는 모든 값에 대해서 양쪽 모두의 연산자가 불리언 값을 돌려주고, (x A y)가 NOT (x B y)와 동일한 경우, 연산자 A는 연산자 B의 부정자라고 말합니다. 또, B는 A의 부정자이기도 한 것에 주의해 주세요. 예를 들면, 대부분의 데이터형에서는 <와 >=는 부정자 쌍이 됩니다. 연산자가 자신의 부정자가 되는 일은 결코 없습니다.
교환 연산자와 달리, 단항 연산자 쌍은 서로 부정자로서 유효하게 지정됩니다. 즉, 모든 x에 대해서 (A x)가 NOT (B x)와 동일함을 의미합니다. 오른쪽 단항 연산자에서도 같습니다.
어느 연산자의 부정자는, 그 연산자 정의의 왼쪽 오퍼랜드, 오른쪽 오퍼랜드와 같은 형태를 가져야 합니다. 즉, COMMUTATOR구와 같게 연산자의 이름만 NEGATOR구로 줄 뿐입니다.
NOT (x = y)라는 식을 x <> y라고 하는 형태에 단순화 시키는 것이 가능해서, 부정자가 있는 것이 쿼리 최적화에 있어 매우 도움이 됩니다. 다른 재배치의 결과로서 NOT조작이 삽입되는 경우가 있기 때문에, 이 현상은 생각했던 것보다 빈번하게 일어납니다.
부정자 쌍은, 위의 교환자의 쌍으로 설명한 방법과 같은 방법으로 정의할 수가 있습니다.
RESTRICT구가 주어졌을 경우, 그것은, 그 연산자용의 제한 선택 추정 함수를 지정합니다 (연산자명이 아니고 함수명인 것에 주의해 주세요). RESTRICT구는 boolean형을 돌려주는 2항연산자에 대해서만 유효합니다. 제한 선택 추정의 목적은, 현재의 연산자와 특정의 정수값에 대한 WHERE구
column OP constant
의 조건을 채우는 테이블 내의 행의 비율을 추측하는 것입니다. 이 형식을 가진 WHERE구에 의해, 어느 정도의 행이 제거되는지를 통지하는 것으로, 최적화를 돕습니다 (정수값이 좌항에 있으면 무엇이 일어나는지 의문이 생길지도 모릅니다만, 그것은 COMMUTATOR가 존재하는 이유의 하나이기도 합니다).
새로운 제한 선택 추정 함수의 기술 방법은 본장의 내용을 넘고 있습니다만, 다행스럽게도, 많은 사용자 정의의 연산자에 대해 통상 몇 개의 시스템 표준의 추정 함수를 사용하면 충분합니다. 시스템 표준의 제한 추정 함수에는 아래와 같은 것이 있습니다.
=용무의 eqsel
|
<>용의 neqsel
|
< 또는 <=용의 scalarltsel
|
> 또는 >=용의 scalargtsel
|
이러한 분류가 되어 있는 것이 이상하게 보일지도 모릅니다만, 다음과 같은 일을 상정하면 그만한 의미가 있는 것이 이해할 수 있습니다. =는 특히 테이블 내 행의 작은 부분을 받아들입니다. <>는 특히 작은 부분을 제외합니다. <는, 지정한 정수가 테이블열이 취하는 값의 범위의 근처 어디에 위치하는지에 의존하는 부분을 받아들입니다 (이것은 자주 발생하는 것입니다. ANALYZE에 의해 수집되는 정보로, 선택 추정 함수로 사용할 수 있도록 작성됩니다). <=는, 같은 정수 비교에 있어 <보다 약간 큰 부분을 받아들입니다. 특히 대략적인 추측 이상을 실시하는 것은 적절하지는 않기 때문에, 구별할 가치가 없다고 할 수 있을 정도로 근사한 값입니다. >와 >=에 대해서도 동일한 적용을 말할 수 있습니다.
매우 높거나 또는 매우 낮은 선택성을 가지는 연산자가, 완전히 동일한지 아닌지도 상관없이,
eqsel 또는 neqsel를 사용하지 않는 것도 때때로 가능합니다.
예를 들면, 근사 등호의 기하 연산자는 테이블의 엔트리의 오부분에만 합치하는 것을 가정해 eqsel를 사용합니다.
범위 비교를 위해서 수치 스칼라로 변환하는 것에 예민한 데이터형을 비교하기 위해서,
scalarltsel과 scalargtsel를 사용하는 것이 가능합니다.
할 수 있으면 src/backend/utils/adt/selfuncs.c의
convert_to_scalar()의 기능으로 이해 가능한 데이터형을 추가해 주세요
(향후, 이 기능은, 아직 행해지지 않은 것으로, pg_type시스템 목록의 열로 식별된, 데이터형 별 함수로 옮겨질 수 있어야 합니다.).
이것을 실시하지 않아도 움직입니다만, 최적화는 본래의 추측 기능을 충분히 발휘할 수 없습니다.
기하 연산자에 대한 추가 선택 추정 함수 areasel, positionsel, contsel는
src/backend/utils/adt/geo_selfuncs.c에 쓰여져 있습니다.
본장의 집필 시점에서는, 이것들은 단순한 그루터기입니다만, 어쨌든 사용하고 싶은(혹은 개선하고 싶다)것도 있을 것입니다.
JOIN구가 주어졌을 경우, 그것은 그 연산자의 결합 선택 추정 함수의 이름을 나타냅니다 (이것이 연산자명이 아니고 함수명인 것에 주의해 주세요). JOIN구는 boolean형을 돌려주는 2항연산자만 유효합니다. 결합 선택 추정의 목적은, 현재의 연산자에 대해, WHERE구
table1.column1 OP table2.column2
를 채우는 테이블 내 행의 비율을 추측하는 것입니다. RESTRICT구의 사용과 같이, 몇 개의 취할 수 있는 결합 순서 가운데, 어떤 것이 가장 작업량이 적게 생각되는지를 계산시키는 것으로, 최적화를 실질적으로 돕습니다.
이전과 같이, 본장에서도 통합 선택 추정 함수의 작성 방법은 설명하지 않습니다. 적용할 수 있는 것이 있으면, 표준 추정 함수의 사용을 추천합니다.
=용무의 eqjoinsel |
<>용의 neqjoinsel
|
< 혹은 <=용의 scalarltjoinsel
|
> 혹은 >=용의 scalargtjoinsel
|
2 차원 면적을 기본으로 한 비교용의 areajoinsel
|
2 차원 위치를 기본으로 한 비교용의 positionjoinsel
|
2 차원 함유 관계를 기본으로 한 비교용의 contjoinsel
|
HASHES구가 존재하는 경우, 그것은 시스템에 대해서, 이 연산자에 근거한 결합에 해시 결합 방법을 사용해도 문제가 없는 것을 말합니다. HASHES구는 boolean형을 돌려주는 2항연산자에게만 유효합니다. 실제로는, 이 연산자는, 어느 데이터형의 등가성을 표현해야 합니다.
해시 결합의 기초가 되고 있는 가정은, 결합 연산자는 좌항과 우항의 값이 같은 해시 코드를 가질 때에만 참을 돌려줄 수 있는 것입니다. 2개의 값이 다른 해시 버킷에 놓여졌을 경우, 결합 연산자의 결과가 반드시 거짓이라는 가정을, 암묵적으로 결합을 실시해, 그것들을 비교하지 않습니다. 따라서, 어떠한 등가성을 나타내지 않는 연산자에 HASHES구를 지정하는 것은 전혀 의미가 없습니다.
HASHES표시를 하기 위해서, 결합 연산자는 해시 인덱스의 연산자 클래스내에 있어야 합니다. 연산자를 작성할 때에는 참조하는 연산자 클래스가 아직 존재하지 않으므로, 연산자의 작성시에 이것은 실행되지 않습니다. 그러나, 연산자 클래스가 존재하지 않는 경우에, 이 연산자를 해시 결합으로 사용하려고 하면, 실행시에 실패합니다. 시스템은, 연산자의 입력 데이터형의 데이터형 특유 해쉬 함수를 검색하기 위해서, 연산자 클래스를 필요로 합니다. 물론, 연산자 클래스를 작성하기 전에 적절한 해쉬 함수를 작성해야 합니다.
해쉬 함수를 준비할 때에는 주의가 필요합니다.
머신에 의존하는 것으로부터, 해시 결합이 적절한 처리를 실시하지 않고 실패하기 때문입니다.
예를 들면, 데이터형이 불필요한 비트를 가질 가능성이 있는 구조인 경우,
(추천하는 전략인, 다른 연산자와 함수를 작성해, 불필요한 비트가 항상 제로가 되는 것을 보증하지 않는 한,) 그 구조 전체를
단순하게 hash_any에 건네줄 수 없습니다.
이 다른 예로서 IEEE부동 소수점 표준을 채우는 머신에서는, 마이너스 0으로 플러스 0은 다른 값(다른 비트열)이 됩니다만,
이 비교는 등가라고 정의됩니다.
부동 소수점수(실수)값이 마이너스 0을 가질 가능성이 있다면, 그것이 플러스 0으로 같은 해시 코드를 확실히 생성하는 것 같은 처치가 필요합니다.
Note: 해시 결합 가능 연산자의 기가 되는 함수는 immutable 혹은 stable가 아니면 안됩니다. volatile의 경우, 시스템은 그 연산자를 결코 해시 결합에 사용하지 않습니다.
Note: 해시 결합 가능 연산자의 배후의 함수가 정밀한 경우, 그 함수가 완성됩니다. 즉 2개의 비NULL 입력에 대해서, 참 또는 거짓을 돌려주고, 절대 NULL을 돌려주지 않아야 합니다. 이 규칙에 따르지 않으면 IN조작에 있어서의 해시 최적화는 잘못된 결과를 생성할 가능성이 있습니다 (특히, 표준에 따르면 NULL가 올바른 대답이 되는 곳에 IN는 거짓을 돌려줄지도 모릅니다. 혹은, NULL라고 하는 결과에 대한 준비되지 않은 에러를 생성할지도 모릅니다).
MERGES구가 존재하는 경우, 그것은 시스템에 대해서, 이 연산자에 근거한 결합에 병합 결합 방법을 사용해도 문제가 없는 것을 말합니다. MERGES구는 boolean형을 돌려주는 2항연산자에만 유효합니다. 실제로는, 연산자가 데이터형 또는 데이터형 쌍의 등가성을 나타내야 합니다.
병합 결합은, 좌측의 테이블, 우측의 테이블을 순서를 잘 정렬 해, 병렬에 스캔 한다고 하는 생각에 근거하고 있습니다. 따라서, 두 데이터형 모두는 완전한 순서부 기능이 필요하고, 결합 연산자는 정렬순서로 "같은 장소"에 있는 값의 쌍 만을 성공한 것으로 해야만 합니다. 실제로 이것은, 결합 연산자는 등가성과 같은 행동을 해야 하는 것을 의미합니다. 그러나, 병합 결합은 논리적인 호환성을 가지는 다른 2개의 데이터형을 취할 수 있습니다. 예를 들면, smallint 대 integer의 등가성 연산자는 병합 결합이 가능합니다. 양쪽 모두의 데이터형을 논리적인 호환성을 유지하는 시퀀스로 정렬하는 연산자만이 필요합니다.
병합 결합의 실행은 시스템이 병합 결합 등가성 연산자와 관련된 4개의 연산자로 식별할 수 있어야 합니다. 왼쪽 오퍼랜드 데이터형과 비교한 것보다 작고, 오른쪽 오퍼렌드 데이터형과 비교한 것보다 작고, 두 데이터형의 비교보다 작고, 두 데이터형의 비교보다 큰 경우들이 있습니다. (이것들은 병합 결합가능한 연산자가 두 개의 다른 오퍼랜드 데이터 형을 가지고 있을 때, 사실상 네 개의 별개의 연산자가 됩니다. 그러나, 오퍼랜드 형이 세개 이하의 연산자와 같을 때 연산자는 모두 같은 연산자입니다.) 이런 연산자들을 이름을 SORT1, SORT2, LTCMP, 와 GTCMP 옵션 처럼 각각 개별적으로 지정할 수 있습니다. 시스템은 MERGES를 지정할 때 이 중 어느 것이 생략되는 경우, 기본값명에 <, <, <, >를 각각 넣을 수 있습니다. 또한, MERGES는 네 연산자 옵션이 생긴 것을 수반하는 것을 가정합니다. 따라서, 연산자 옵션을 지정하고, 시스템에 그 나머지를 넣는 것을 가능하게 합니다.
네 개의 비교 연산자의 오퍼랜드 데이터형은 병합 결함가능 연산자의 오퍼랜드형으로부터 추론될 수 있습니다. 단지 COMMUTATOR를 사용할 때 처럼, 필요한 연산자 이름만이 이 절에 주어집니다. 특수한 연산자 이름을 선택하여 사용하는 경우가 아니라면, MERGES를 쓰거나 시스템 세부사항에 넣는 것으로 충분합니다. (COMMUTATOR와 NEGATOR의 경우 처럼, 이 전의 다른 연산자와 동종임을 정의할 때, 시스템은 가짜의 연산자 엔트리를 만들 수 있습니다.)
병합 가능한지 확인해야 하는, 연산자에 대한 추가적 제약이 있습니다 이러한 제약들은 현재 CREATE OPERATOR에 의해 확인되고 있지 않습니다만, 에러는 연산자가 참이 아닌 경우 사용될 때 발생합니다.
병합 가능 동일 연산자는 반드시 병합 결합하능 교환자여야 합니다. (두 오퍼랜드 데이터형이 같을 경우, 또는 데이터형은 다르지만 동일 연산자에 관련될 경우)
병합 결합 가능 연산자와 연관된 두 데이터형 A와 B, 그리고 B와 연관된 병합 결합 가능 연산자 또 다른 세 전째 데이터형 C가 있는 경우, A와 B는 반드시 병합 결합 가능한 연산자여야 하며, 이것은 병합 가능 연산자가 전이되어야 한다는 말이기도 합니다.
이름 붙인 네 개의 비교 연산자의 데이터 값을 적합하게 정렬하지 않으면, 이상한 결과가 실행하는 동안에 나타날 것입니다.
Note: 병합 결합 가능 연산자의 배후에 있는 함수는 immutable 혹은 stable가 아니면 안됩니다. volatile의 경우, 시스템은 그 연산자를 결코 병합 결합에 사용하려고 하지 않습니다.
Note: 7.3 이전의 버전PostgreSQL에는, MERGES 속기는 허용되지 않습니다. 병합 결함 가능한 연산자는 SORT1와 SORT2 모두 명시적으로 기록해야 합니다. 또한, LTCMP와 GTCMP 옵션은 존재하지 않습니다. 이 연산자명이 <와 > 같이 각각 직접 기록되었기 때문입니다.