| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 35. 룰 시스템 | Fast Forward | Next |
트리거에 의해 행해지는 많은 조작은 PostgreSQL의 룰 시스템으로 구현 가능합니다. 룰로 구현할 수 없는 1개는 어떤 종류의 제약, 특히 외부 키에 관계되어있습니다. 만약 다른 테이블에 열의 값이 없었던 경우, 조건 룰로 명령을 NOTHING에 고쳐 써 버리는 일도 가능합니다만, 이것으로는 데이터가 조용히 소거되어 버려, 좋은 아이디어라고는 말할 수 없습니다. 유효한 값인지 아닌지 체크가 필요해, 무효인 값에 대해서는 에러 메세지를 표시할 필요가 있다면, 이것은 현재 트리거를 사용해 실시하지 않으면 안됩니다.
한편, 뷰상에서 INSERT에 의해 기동된 트리거는, 데이터를 어딘가로 보내, 뷰에의 삽입을 금지하는 룰과 같은 것이 생깁니다. 그러나 UPDATE 또는 DELETE에서는, 검색되는 실제 데이터가 뷰 릴레이션에 존재하지 않고, 트리거가가 불리는 일이 없기 때문에, 룰과 같은 것을 실시할 수가 없습니다. 룰로 해결할 수 밖에 없습니다.
어디라도 구현할 수 있는 사항에 관해서 어느 쪽이 최선인지는 데이터베이스의 사용법에 따릅니다. 트리거는 어느 행에 대해서도 한 번만 기동합니다. 룰은 쿼리를 조작하는 추가의 쿼리를 생성합니다. 그러니까, 1개의 명령문이 많은 행에 영향을 주는 경우, 1개의 행을 처리할 때에 불려 가 그 실행을 몇번이나 실시해야 하는 트리거보다, 추가의 쿼리를 1개 발행하는 룰이 대부분의 경우 더 빠릅니다. 그러나, 트리거 방식은 개념적으로 룰 시스템보다 꽤 단순하고, 초심자는 간단하고 바르게 취급할 수가 있습니다.
여기서, 어느 상황에서 룰과 트리거의 어느 쪽을 선택하는지를 나타내는 예를 듭니다. 예를 들면, 2개의 테이블이 있다고 합니다.
CREATE TABLE computer (
hostname text, -- 인덱스된
manufacturer text -- 인덱스된
);
CREATE TABLE software (
software text, -- 인덱스된
hostname text -- 인덱스된
);
2개의 테이블에는 함께 수천 행이 있어, hostname상의 인덱스는 독특합니다. 룰/트리거는 삭제된 호스트를 참조하는, software의 행을 삭제하는 제한을 구현하지 않으면 안됩니다. 트리거의 경우는 이하의 명령을 사용합니다.
DELETE FROM software WHERE hostname = $1;
computer로부터 삭제된 행, 하나 하나에 대해서 이 트리거가 불려 가기 때문에, 이 명령의 준비를 실시해, 계획을 보존해, 매개변수로서hostname를 건네줄 수가 있습니다. 룰의 경우는 이하와 같이 작성됩니다.
CREATE RULE computer_del AS ON DELETE TO computer
DO DELETE FROM software WHERE hostname = OLD.hostname;
여기서 다른 종류의 삭제를 생각해 봅시다.
DELETE FROM computer WHERE hostname = 'mypc.local.net';
위와 같은 경우에서는 computer는 인덱스에 의해(고속으로) 검색됩니다. 트리거에 의해 이 명령이 발행되었을 경우도 인덱스 검색이 사용됩니다(고속으로). 룰에 의한 추가 명령은 이하와 같이 됩니다.
DELETE FROM software WHERE computer.hostname = 'mypc.local.net'
AND software.hostname = computer.hostname;
적절한 인덱스가 설정되어 있기 때문에, 플래너는 이하의 계획을 작성합니다.
네스트루프 -> computer에 대해 comp_hostidx를 사용한 인덱스 스캔 -> software에 대해 soft_hostidx를 사용한 인덱스 스캔
그러므로, 트리거와 룰의 구현 간 속도차이는 그다지 없습니다.
다음의 삭제 처리에서는 hostname가 old로 시작되는 2,000대 모든 computer를 삭제하려고 합니다. 방법으로서 2개의 유효한 쿼리가 있는데, 그 중 1개는 이하와 같은 것입니다.
DELETE FROM computer WHERE hostname >= 'old'
AND hostname < 'ole'
룰에 의해 추가되는 명령은 이하와 같이 됩니다.
DELETE FROM software WHERE computer.hostname >= 'old' AND computer.hostname < 'ole'
AND software.hostname = computer.hostname;
이것에 대한 계획은 이하와 같이 됩니다.
해시 결합
-> software에 대한 시퀀셜 검색
-> 해시
-> computer에 대한 comp_hostidx를 사용하는 인덱스 스캠
다른 1개의 명령은 이하와 같은 것입니다.
DELETE FROM computer WHERE hostname ~ '^old';
이것에 의해, 룰에 의해 추가되는 명령의 실행 계획은 이하와 같이 됩니다.
상자장 루프 -> computer에 대한 comp_hostidx를 사용하는 인덱스 검색 -> software에 대한 soft_hostidx를 사용하는 인덱스 검색
이것이 가리키고 있는 것은, AND로 결합된 복수의 검색 조건이 존재하는 경우, 플래너는 정규 표현 버전의 명령에서는 하고 있는 것이지만, computer상의 hostname에 대한 검색 조건을 software상의 인덱스 검색과 같이 사용할 수 있는 것을 이해하지 않는다는 것입니다. 트리거는 삭제되어야 할 2,000대의 구식 컴퓨터의 각각 붙어 1회불려 가 결과computer상에서 1회의 인덱스 검색과 software상에서 2,000회의 인덱스 검색을 합니다. 룰에 의한 구현에서는 인덱스를 사용하는 2개의 쿼리에 의해 실행됩니다. 시퀀셜 검색의 경우에서도 룰이 보다 빠른지 어떤지는 software테이블의 크기에 의존합니다. 참조하는 모든 인덱스 블록이 곧바로 캐쉬에 나타난다고 해도, SPI 관리자는 트리거에 의한 2,000회의 명령의 실행에는 시간을 필요로 합니다.
마지막 명령을 봅시다.
DELETE FROM computer WHERE manufacturer = 'bim';
이 문장에서도 computer로부터 많은 행이 삭제되는 결과가 됩니다. 그러므로, 여기에서도 트리거는 집행자를 통해 많은 명령을 실행하게 됩니다. 룰로 작성되는 명령은 이하와 같은 것입니다.
DELETE FROM software WHERE computer.manufacturer = 'bim'
AND software.hostname = computer.hostname;
이 명령용의 계획도 이전같이 2개의 인덱스 검색의 네스트루프가 됩니다.
네스트루프 -> computer에 대한 comp_manufidx를 사용하는 인덱스 검색 -> software에 대한 soft_hostidx를 사용하는 인덱스 검색
어느 경우에 대해서도, 룰 시스템이 생성하는 추가 명령은 영향을 받는 행수로부터는 많든 적든 독립하고 있습니다.
정리하면, 쿼리 결과가 크고, 플래너가 결합 조건을 잘 설정할 수 없는 것과 같은 상황하에서만 룰은 트리거에 비해 분명하게 늦어집니다.