| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 17. 서버의 설정 | Fast Forward | Next |
이러한 설정 매개변수는, 문의 최적화가 선택하는 문의 계획에 영향을 주는 대략적인 수법을 제공합니다. 어느 문의에 대해서 최적화가 선택한 디폴트 계획이 최적이지 않은 경우, 잠정적인 해결책은, 이러한 설정 매개변수의 하나를 사용해, 최적화에 다른 계획을 선택하도록 대하는 것입니다. 그러나, 영구적으로 이러한 설정을 무효로 하는 것은 그다지 권유받지 않습니다. 품질을 개선하는 방책은, 다음과 같이 하여 최적화가 선택할 계획의 품질을 향상하는 것입니다. planner 코스트 상수 (을)를 조절해, ANALYZE 를 보다 빈번하게 실행해,default_statistics_target설정 매개변수의 값을 크게 합니다, 그리고ALTER TABLE SET STATISTICS를 사용해, 특정의 열에 대해서 수집된 통계 정보를 늘립니다.
문의 planner가 비트 맵 스캔 계획형을 선택하는 것을 유효 혹은 무효로 합니다. 디폴트는on입니다.
문의 planner가 해시 된 집계 계획형을 선택하는 것을 유효 혹은 무효로 합니다. 디폴트는on입니다.
문의 planner가 해시 결합 계획형을 선택하는 것을 유효 혹은 무효로 합니다. 디폴트는on입니다.
문의 planner가 인덱스 주사 계획형을 선택하는 것을 유효 혹은 무효로 합니다. 디폴트는on입니다.
문의 planner가 머지 결합 계획형을 선택하는 것을 유효 혹은 무효로 합니다. 디폴트는on입니다.
문의 planner가 nested 루프 결합 계획을 선택하는 것을 유효 혹은 무효로 합니다. nested 루프 결합을 완전하게 금지하는 것은 불가능합니다만, 이 변수를 오프로 하면, 만약 다른 방법을 이용할 수 있다면, planner는 그 사용을 실시하지 않게 됩니다. 디폴트는on입니다.
문의 planner가 시퀀셜 스캔 계획형을 선택하는 것을 유효 혹은 무효로 합니다. 시퀀셜 주사를 완전하게 금지하는 것은 불가능합니다만, 이 변수를 오프로 하면, 만약 다른 방법을 이용할 수 있다면, planner는 그 사용을 실시하지 않게 됩니다. 디폴트는on입니다.
문의 planner가 명시적 정렬 단계를 사용하는 것을 유효 혹은 무효로 합니다. 명시적 정렬을 바꾸고를 완전하게 금지하는 것은 불가능합니다만, 이 변수를 오프로 하면, 만약 다른 방법을 이용할 수 있다면, planner는 그 사용을 실시하지 않게 됩니다. 디폴트는on입니다.
문의 planner가TID주사 계획형을 선택하는 것을 유효 혹은 무효로 합니다. 디폴트는on입니다.
본절로 취급하는코스트변수는, 임의의 척도로 측정됩니다. 이것들은 상대적인 값 밖에 없습니다. 그 때문에, 같은 인자로 척도를 바꾸어도, planner의 선택은 결과적으로 바뀌지 않습니다. 전통적으로, 이러한 변수는 코스트 단위로서 시퀀셜인 페이지 혼잡을 참조하고 있었습니다. 즉,seq_page_cost를 관습적으로1.0으로 해, 다른 코스트 변수를 그것을 참고(?설정되어 있었습니다. 그러나 원한다면, 특정의 머신에 있어서의 밀리 세컨드 단위의 실행 시간 등, 다른 척도를 사용할 수가 있습니다.
Note: 유감스럽지만, 코스트 변수에 대한 이상적인 값을 결정하는, 능숙하게 정의된 방법이 없습니다. 특정의 설치가 실시되는 문의 전체를 혼재시킨 것의 평균을 최선의 것으로 다루어지고 있습니다. 몇차례의 실험만을 근거로 이 값을 변경하는 것은 위험하다라고 말할 수 있습니다.
시퀀셜인 일련의 취득의 일부가 되는, 디스크 페이지 패치에 관한, planner의 추정 코스트를 설정합니다. 디폴트는 1.0입니다.
비순서적으로 꺼내지는 디스크 페이지의 코스트에 대한 planner의 추측을 설정합니다. 디폴트는 4입니다. 이 값을seq_page_cost에 상대적으로 감소시키면, 시스템은 인덱스 스캔을 기꺼이 사용하게 됩니다. 증가시키면, 인덱스 스캔이 상대적으로 고가로 됩니다. 양쪽 모두의 값을 증감시키는 것으로, CPU 코스트에 대한 디스크 I/O의 중요성을 변경시킬 수가 있습니다. 이것에 대해서는, 후술의 매개변수로 설명합니다.
Tip: 시스템은random_page_cost를seq_page_cost보다 작은 값으로 설정하려고 합니다만, 이것에는 물리적인 의미는 없습니다. 그러나, 데이터베이스가 완전하게 RAM에 캐시되는 경우, 같은 값으로 설정하는 것은 의미를 가집니다. 이 경우, 순서 대로가 아닌 페이지 액세스에 대한 패널티가 존재하지 않기 때문입니다. 또, 대부분이 캐시되는 데이터베이스에서는, CPU 매개변수에 대해서 양쪽 값을 작게 설정해야 합니다. RAM내에 존재하는 페이지의 꺼낸 코스트는 통상보다 훨씬 작기 때문입니다.
문의간에 각각의 행의 처리에 대한 planner의 추측을 설정합니다. 디폴트는 0.01입니다.
인덱스 스캔간에 각각의 인덱스행의 처리에 대한 planner의 추측을 설정합니다. 디폴트는 0.005입니다.
문의시에 실행되는 각 연산자나 함수의 처리 코스트에 대한 planner의 추측을 설정합니다. 디폴트는 0.0025입니다.
단일의 문의로 이용할 수 있는 디스크 캐시 프로그램의 실효 용량에 관한 planner의 가정을 설정합니다. 이것은, 인덱스를 사용하는 코스트 추정치의 요소가 됩니다. 보다 비싼 값으로 하면, 보다 많은 인덱스 스캔이 사용되게 되어, 보다 작게 설정하면, 시퀀셜 스캔이 좀더 사용되게 됩니다. 이 매개변수를 설정할 때에는,PostgreSQL의 공유 버퍼와PostgreSQL데이터 파일에 사용되는 커넬의 디스크 캐시 프로그램의 양의 양쪽 모두를 고려하지 않으면 안됩니다. 또, 이용 가능한 영역을 공유하기 때문에, 다른 테이블에 대해서 동시에 실행되는 문의의 예상되는 총정수도 고려해 주세요. 이 매개변수는,PostgreSQL로 할당할 수 있는 공유 메모리의 크기에는 영향을 주지 않습니다. 또, 커넬의 디스크 캐시 프로그램을 예약하지도 않습니다. 이것은 추정 목적만으로 사용됩니다. 디폴트는 128 메가바이트(128MB)입니다.
exhaustive검색을 실시하지 않고 문의 계획을 시도하는 알고리즘인, 유전적 문의 최적화를 유효 또는 무효로 합니다. 디폴트는 온입니다. geqo_threshold변수는, 어느 문의의 클래스에 대해, GEQO를 무효로 하는 것보다 치밀한 방법을 제공합니다.
적어도 이만큼의 수의FROM항목수로 문의를 계획하는데 유전적 문의 최적화를 사용합니다. (FULL OUTER JOIN의 생성자는, 1개의FROM항목으로서 계산하는 것에 주의해 주세요. ) 디폴트는 12입니다. 좀 더 단순한 문의에서는, 결정론적, exhaustive planner를 사용하는 것이 최선입니다만, 많은 테이블을 가지는 문의에서는, 결정론적 planner는 매우 시간이 걸립니다.
GEQO에 있어서의 계획 시간과 문의 계획의 효율성의 사이의 트레이드 오프를 제어합니다. 이 변수는 1에서 10까지의 범위의 정수가 아니면 안됩니다. 디폴트의 값은 5입니다. 값을 크게 하면, 문의 계획 작성에 의해 많은 시간을 소비한 것이 됩니다만, 보다 효율적인 문의 계획이 선택될 가능성이 증가합니다.
실제geqo_effort는 직접 아무것도 실시하지 않습니다. 그것은 GEQO의 행동에 영향을 주는 다른 변수에 대해, 디폴트의 값을 계산하기 위해서만 사용됩니다(이하에서 설명합니다). 원하는 경우, 수작업 대신에, 다른 매개변수를 설정할 수 있습니다.
GEQO로 사용되는 풀 용량을 관리합니다. 풀 용량과는 유전적 모집단내의 개체수입니다. 적어도 2개 이어야 하며, 100에서 1000까지의 값이 사용됩니다. 만약(디폴트의 설정이다) 영으로 설정되면,geqo_effort및 문의 안의 테이블수에 근거해, 적절한 디폴트가 선택됩니다.
GEQO로 사용되는 세대의 수를 관리합니다. 세대는 알고리즘의 반복수를 지정합니다. 최악이어도 1은 없으면 안되어, 풀 사이즈와 같은 범위의 값이 사용됩니다. 이것을 0으로 설정(디폴트의 설정)하면, 적절한 디폴트치가geqo_effort에 근거해 선택됩니다.
GEQO로 사용되는 표본선택 편의을 관리합니다. 표본선택 편의는 모집단내의 선택적인 압력입니다. 값은 1.50에서 2.00으로, 2.00이 디폴트입니다.
ALTER TABLE SET STATISTICS로 특정한 열의 대상 집합을 소유하고 있지 않았던 테이블열에 대해, 디폴트의 통계 대상을 설정합니다. 보다 큰 값은ANALYZE에 필요한 시간을 증가시킵니다만, planner의 예측의 품질을 향상시킵니다. 디폴트는 10입니다. PostgreSQL의 문의 planner에 의한 통계 정보의 사용법에 관한보다 상세한 정보는,Section 13.2을 참조해 주세요.
문의를 최적화하기 위한 테이블 제한의 문의 planner의 사용을 유효 혹은 무효로 합니다. 디폴트는off입니다.
이 매개변수가on시에는, planner는 테이블CHECK제약으로 문의 조건을 비교해, 제약과 모순되는 조건의 스캐닝 테이블을 삭제합니다. 예를 들면 이하와 같이 됩니다.
CREATE TABLE parent(key integer, ...); CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent); CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent); ... SELECT * FROM parent WHERE key = 2400;
제약 배제가 유효하고, 이SELECT는 전혀child1000를 스캔하지 않습니다. 이것은 상속이 파티션된 테이블의 작성에 사용될 때, 성능을 향상시킵니다.
현시점에서constraint_exclusion의 디폴트는 무효입니다. 쿼리 계획이 캐시되는 경우, 잘못된 결과를 가져올 위험성이 있기 때문입니다. 테이블 제약이 변경 또는 삭제되는 경우, 이전에 생성된 계획이 지금은 잘못되었을 가능성이 있습니다. 그리고 재계획을 강용하는 내장된 매커니즘이 있습니다. (이 결함은, 향후에 PostgreSQL릴리스에서 논의 됩니다.) 또 다른 이유는 제약 검사가 비교적 고가여서, 많은 경우에 구제를 가져오지 않기 때문입니다 이 기능의 장점을 이용해 설계된 만큼 비율 된 테이블을 실제로 사용하고 있는 (분)편 마셔, 이것을 유효하게 하는 것을 추천 합니다.
제약에 의한 제외 및 파티셔닝에 관한 자세한 것은Section 5.9을 참조해 주세요.
planner는,FROM리스트가 이들 항목보다 적은 결과의 경우, 서브쿼리를 상위의 쿼리에 병합 합니다. 보다 작은 값은 계획 시간을 축소시킵니다만, 열등한 쿼리 계획을 가져올 가능성이 있습니다. 디폴트는 8입니다. 통상 이것을geqo_threshold이하로 해 두면 좋을 것입니다. 자세한 것은Section 13.3을 참조해 주세요.
최종적으로 리스트가 이 항목수 이하가 될 때, planner는, 명시적인JOIN구문(FULL JOIN를 제외한다)을FROM항목의 리스트로 재작성합니다. 이 값을 작게 하면 계획 작성 시간은 감소합니다만, 열등한 쿼리 계획이 작성될 가능성이 있습니다.
디폴트에서는, 이 값은from_collapse_limit와 같은 값으로 설정되어 있어 대부분의 경우에 적절합니다. 이것을 1로 설정하면, 명시적인JOIN의 재순서하는 것을 방지 합니다. 따라서, 쿼리로 지정된 명시적 결합 순서는, 릴레이션이 결합되는 실제의 순서가 됩니다. 쿼리 플래너는 항상 최적인 결합 순서를 선택한다고는 할 수 없습니다. 상급 유저라면 잠정적으로 이 변수를 1로 설정해, 명시적으로 희망으로 하는 결합 순서를 지정해도 괜찮을 것입니다. 자세한 것은Section 13.3을 참조해 주세요.