챕터 11. 스포츠 토토 베트맨 팁

11.1. 사용설명

스포츠 토토 베트맨고안쿼리 계획각 쿼리에 대해 제공됩니다. 쿼리 구조와 쿼리 구조에 맞는 올바른 계획 선택 데이터의 속성은 좋은 결과를 위해 절대적으로 중요합니다. 스포츠 토토 베트맨. 다음을 사용할 수 있습니다.설명시스템이 어떤 쿼리 계획을 생성하는지 확인하는 명령 쿼리. 계획 읽기는 광범위한 연구를 할 가치가 있는 예술입니다. 이것은 튜토리얼이 아닙니다. 하지만 여기에는 몇 가지 기본 사항이 있습니다. 정보.

현재 인용된 숫자설명다음은:

• 예상 시작 스포츠 토토 베트맨(출력까지 소요되는 시간) 스캔이 시작될 수 있습니다(예: SORT에서 정렬을 수행할 시간). 노드).

• 예상 총 비용(모든 튜플이 검색된 경우, 그렇지 않을 수도 있습니다 --- LIMIT가 포함된 쿼리는 다음 값에 도달하지 못할 것입니다. 예를 들어 총 비용을 지불합니다.

• 이 계획 노드에서 출력되는 예상 행 수 (다시 말하지만, LIMIT에 관계없이).

• 다음에 의해 출력된 행의 예상 평균 너비(바이트) 이 계획 노드.

비용은 디스크 페이지 가져오기 단위로 측정됩니다. (CPU 노력 추정치는 다음을 사용하여 디스크 페이지 단위로 변환됩니다. 상당히 임의적인 퍼지 요인. 실험해보고 싶다면 이러한 요소는 런타임 구성 목록을 참조하세요. 의 매개변수관리자 안내.)

상위 노드의 비용은 모든 하위 노드의 비용이 포함됩니다. 그것은 또한 중요하다 비용은 단지 그 비용이 반영하는 것만을 반영한다는 것을 깨닫는 것입니다. 플래너/옵티마이저가 관심을 갖고 있습니다. 특히 비용이 들지 않는다. 결과 튜플을 프론트엔드 --- 이는 게임 내에서 매우 지배적인 요소가 될 수 있습니다. 실제 경과 시간이지만 플래너는 이를 무시합니다. 계획을 변경하여 변경하세요. (모든 올바른 계획이 출력됩니다. 동일한 튜플 세트라고 믿습니다.)

행 출력은 약간 까다롭습니다.아님행 수 쿼리에 의해 처리/스캔됨 --- 일반적으로 더 적습니다. WHERE 절의 예상 선택성을 반영합니다. 이 노드에 적용되는 제약 조건입니다. 이상적으로는 최상위 행 추정치는 대략적인 행 수입니다. 실제로 쿼리에 의해 반환, 업데이트 또는 삭제되었습니다.

다음은 몇 가지 예입니다(회귀 테스트 데이터베이스 사용). 진공 분석 및 7.2 개발 소스 후):

regression=# EXPLAIN SELECT * FROM tenk1;
공지: 쿼리 계획:

tenk1의 시퀀스 스캔(비용=0.00..333.00행=10000너비=148)

이것은 매우 간단합니다. 그렇게 한다면

SELECT * FROM pg_class WHERE relname = 'tenk1';

당신은 그것을 알게 될 것입니다tenk1에는 233개의 디스크 페이지와 10000개의 튜플이 있습니다. 그래서 스포츠 토토 베트맨이 추정됩니다. 233개 페이지 읽기에서 각각 1.0에 10000 *을 더한 것으로 정의됨cpu_tuple_cost현재는 0.01(시도해 보세요)cpu_tuple_cost 표시).

이제 자격을 추가하기 위해 쿼리를 수정합시다 절:

regression=# EXPLAIN SELECT * FROM tenk1 WHERE Unique1 < 1000;
공지: 쿼리 계획:

tenk1의 시퀀스 스캔(비용=0.00..358.00행=1007 너비=148)

출력 행의 추정치가 다음으로 인해 감소했습니다. WHERE 절. 그러나 스캔은 여전히 모든 항목을 방문해야 합니다. 10000행이므로 비용은 감소하지 않았습니다. 사실은 없어졌어 WHERE를 확인하는 데 소요된 추가 CPU 시간을 반영하기 위해 약간 높였습니다. 조건.

이 쿼리가 선택하는 실제 행 수는 1000개입니다. 그러나 추정치는 대략적인 것일 뿐입니다. 복제하려고 하면 이 실험에서는 아마도 약간 다른 결과를 얻게 될 것입니다. 추정; 게다가 매번 변경될 것입니다.분석명령, 왜냐하면 통계가 생성되었기 때문입니다. 으로분석무작위에서 가져옴 테이블 샘플입니다.

쿼리를 수정하여 자격을 다음과 같이 제한하십시오. 더:

regression=# EXPLAIN SELECT * FROM tenk1 WHERE Unique1 < 50;
공지: 쿼리 계획:

tenk1에서 tenk1_unique1을 사용하는 인덱스 스캔(비용=0.00..181.09 행=49 너비=148)

WHERE 조건을 만들면 이를 알 수 있습니다 충분히 선택적이라면 기획자는 결국 다음과 같은 결정을 내릴 것입니다. 인덱스 스캔은 순차 스캔보다 저렴합니다. 이 계획은 인덱스 때문에 50개의 튜플만 방문하면 됩니다. 각 개별 가져오기 비용이 더 비싸다는 사실에도 불구하고 전체 디스크 페이지를 순차적으로 읽는 것보다.

자격에 다른 조건을 추가하십시오:

regression=# EXPLAIN SELECT * FROM tenk1 WHERE Unique1 < 50 AND
회귀-# stri스포츠 토토 베트맨u1 = 'xxx';
공지: 쿼리 계획:

tenk1에서 tenk1_unique1을 사용하는 인덱스 스캔(비용=0.00..181.22행=1너비=148)

추가된 조항stri스포츠 토토 베트맨u1 = 'xxx'은 출력 행 추정치를 줄이지만 스포츠 토토 베트맨은 줄지 않습니다. 여전히 동일한 튜플 세트를 방문해야 합니다.

우리가 설정한 필드를 사용하여 두 테이블을 결합해 보겠습니다. 논의 중:

regression=# EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50
회귀-# AND t1.unique2 = t2.unique2;
공지: 쿼리 계획:

중첩 루프(비용=0.00..330.41행=49너비=296)
  - tenk1 t1에서 tenk1_unique1을 사용한 인덱스 스캔
               (비용=0.00..181.09행=49너비=148)
  - tenk2 t2에서 tenk2_unique2를 사용한 인덱스 스캔
               (비용=0.00..3.01행=1너비=148)

이 중첩 루프 조인에서 외부 스캔은 동일한 인덱스입니다 지난번 예에서 스캔한 결과 스포츠 토토 베트맨과 행이 표시됩니다. 우리가 적용하기 때문에 개수는 동일합니다.고유1 < 50해당 노드의 WHERE 절.t1.unique2 = t2.unique2절이 아님 아직 관련성이 있으므로 외부 스캔의 행 수에는 영향을 미치지 않습니다. 내부 스캔의 경우 현재 외부 스캔의 고유2 값 튜플은 인덱스를 생성하기 위해 내부 인덱스 스캔에 연결됩니다. 자격은 다음과 같습니다t2.unique2 =상수. 그래서 우리는 같은 것을 얻습니다 예를 들어, 내부 스캔 계획 및 스포츠 토토 베트맨을 통해 얻을 수 있는 것입니다.unique2 = 42인 tenk2에서 * 선택 설명. 루프 노드의 비용은 다음을 기준으로 설정됩니다. 외부 스캔 비용 + 내부 스캔 1회 반복 비용 각 외부 튜플(여기서는 49 * 3.01)에 약간의 CPU 시간 추가 조인 처리를 위해.

이 예에서 루프의 출력 행 개수는 다음과 같습니다. 두 스캔의 행 개수를 곱한 값이지만 이는 사실이 아닙니다. 일반적으로 다음과 같은 WHERE 절을 가질 수 있기 때문입니다. 두 관계를 모두 언급하므로 조인 시에만 적용할 수 있습니다. 입력 스캔이 아닌 지점입니다. 예를 들어, 다음을 추가했다면어디서 ... 그리고 t1.hundred < t2.백, 그러면 출력 행 수가 감소합니다. 조인 노드는 변경되지만 입력 스캔은 변경되지 않습니다.

변형 계획을 보는 한 가지 방법은 계획자가 다음을 수행하도록 강제하는 것입니다. 승자라고 생각되는 전략은 무엇이든 무시하고 다음을 사용합니다. 각 계획 유형에 대한 활성화/비활성화 플래그. (이것은 조잡한 것입니다. 도구이지만 유용합니다. 또한 참조하세요섹션 11.3.)

regression=# set 활성화_nestloop = 꺼짐;
변수 설정
regression=# EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50
회귀-# AND t1.unique2 = t2.unique2;
공지: 쿼리 계획:

해시 조인(비용=181.22..564.83행=49너비=296)
  - tenk2 t2의 시퀀스 스캔
               (비용=0.00..333.00행=10000너비=148)
  - 해시(비용=181.09..181.09행=49너비=148)
        - tenk1 t1에서 tenk1_unique1을 사용한 인덱스 스캔
               (비용=0.00..181.09행=49너비=148)

이 계획은 50개의 흥미로운 행을 추출하도록 제안합니다.tenk1동일한 색인을 사용하고 있습니다 스캔하여 메모리 내 해시 테이블에 저장한 다음 순차 스캔tenk2, 가능한 일치를 찾기 위해 해시 테이블을 조사합니다.t1.unique2 = t2.unique2각각tenk2튜플. 읽는 스포츠 토토 베트맨tenk1해시 테이블 설정은 전적으로 해시 조인의 시작 스포츠 토토 베트맨(튜플을 얻지 못하므로) 우리가 읽기 시작할 수 있을 때까지 기다리세요tenk2. 조인에 대한 총 예상 시간 또한 해시를 조사하는 데 소요되는 CPU 시간에 대한 막대한 요금도 포함됩니다. 테이블 10000 번. 그러나 우리는 스포츠 토토 베트맨을 청구하지 않습니다. 10000배 181.09; 해시 테이블 설정은 한 번만 수행됩니다. 이 계획 유형입니다.

기획자의 정확성을 확인할 수 있습니다. EXPLAIN ANALYZE를 사용하여 예상 비용. 이 명령은 실제로 쿼리를 실행한 다음 실제 런타임을 표시합니다. 동일한 추정치와 함께 각 계획 노드 내에 누적됩니다. 일반 EXPLAIN이 보여주는 비용입니다. 예를 들어, 우리는 결과는 다음과 같습니다:

regression=# 분석 설명
회귀-# SELECT * FROM tenk1 t1, tenk2 t2
회귀-# WHERE t1.unique1 < 50 AND t1.unique2 = t2.unique2;
공지: 쿼리 계획:

중첩 루프(비용=0.00..330.41행=49너비=296)(실제 시간=1.31..28.90행=50루프=1)
  - tenk1 t1에서 tenk1_unique1을 사용한 인덱스 스캔
               (비용=0.00..181.09 행=49 너비=148) (실제 시간=0.69..8.84 행=50 루프=1)
  - tenk2 t2에서 tenk2_unique2를 사용한 인덱스 스캔
               (비용=0.00..3.01행=1너비=148) (실제 시간=0.28..0.31행=1루프=50)
총 런타임: 30.67msec

참고하세요"실제 시간"값은 실시간의 밀리초 단위인 반면,"스포츠 토토 베트맨"추정치는 다음과 같이 표현됩니다. 임의의 디스크 가져오기 단위; 그래서 그들은 일치하지 않을 것 같습니다 up. 주목해야 할 것은 비율입니다.

일부 쿼리 계획에서는 하위 계획 노드가 두 번 이상 실행되었습니다. 예를 들어 내부 인덱스 스캔은 다음과 같습니다. 위의 중첩 루프 계획에서 외부 튜플당 한 번씩 실행됩니다. 에서 그러한 경우에는"루프"값 노드의 총 실행 횟수를 보고합니다. 표시된 실제 시간 및 행 값은 실행당 평균입니다. 이는 숫자를 다음과 같은 방식으로 비교하기 위해 수행됩니다. 예상 비용이 표시됩니다. 를 곱한다"루프"실제로 총 시간을 가져오는 값 노드에서 소비되었습니다.

그"총 런타임"표시자: EXPLAIN ANALYZE에는 실행기 시작 및 종료 시간이 포함됩니다. 결과 튜플을 처리하는 데 소요된 시간도 마찬가지입니다. 그렇지 않다 구문 분석, 재작성 또는 계획 시간이 포함됩니다. SELECT의 경우 쿼리를 수행하면 총 런타임은 일반적으로 약간 더 커집니다. 최상위 계획 노드에 대해 보고된 총 시간보다 에 대한 INSERT, UPDATE 및 DELETE 쿼리의 경우 총 런타임은 다음과 같습니다. 소비한 시간이 포함되어 있기 때문에 훨씬 더 큽니다. 출력 튜플을 처리합니다. 이 쿼리에서 시간은 최상위 계획 노드는 기본적으로 다음을 계산하는 데 소요된 시간입니다. 새로운 튜플 및/또는 이전 튜플 찾기. 하지만 여기에는 포함되지 않습니다. 변경하는 데 소요된 시간입니다.

EXPLAIN 결과가 다음과 같지 않아야 한다는 점은 주목할 가치가 있습니다. 실제 상황이 아닌 다른 상황으로 추정 테스트; 예를 들어, 장난감 크기의 테이블에 대한 결과는 큰 테이블에 적용되는 것으로 가정됩니다. 기획자의 비용 추정 선형적이지 않으므로 다른 계획을 선택할 수도 있습니다. 더 크거나 작은 테이블. 극단적인 예는 테이블 위에 있는 것입니다. 하나의 디스크 페이지만 차지하므로 거의 항상 인덱스 사용 가능 여부에 대한 순차 스캔 계획. 는 플래너는 하나의 디스크 페이지를 읽어야 한다는 것을 알고 있습니다. 어떤 경우에도 테이블을 처리하므로 비용을 지출할 가치가 없습니다. 색인을 보기 위해 추가 페이지를 읽습니다.