14.1. 젠 토토젠 토토

14.1.1. 젠 토토기본사항

쿼리 계획의 구조는 트리입니다.계획 노드. 트리의 최하위 수준에 있는 노드 스캔 노드는 테이블의 원시 행을 반환합니다. 있다 다양한 테이블 액세스 방법에 대한 다양한 유형의 스캔 노드: 순차 스캔, 인덱스 스캔, 비트맵 인덱스 스캔이 있습니다. 있다 또한 다음과 같은 테이블이 아닌 행 소스도 있습니다.값절 및 집합 반환 함수발신, 자체 스캔 노드 유형이 있습니다. 만약 쿼리에는 조인, 집계, 정렬 또는 기타 작업이 필요합니다. 원시 행에는 스캔 위에 추가 노드가 있습니다. 이러한 작업을 수행하는 노드입니다. 다시 말하지만 일반적으로 더 많은 것이 있습니다. 이러한 작업을 수행하는 한 가지 가능한 방법이 없으므로 다른 노드 유형도 여기에 나타날 수 있습니다. 의 출력젠 토토계획 트리의 각 노드에 대해 한 줄이 있습니다. 기본 노드 유형과 예상 비용을 보여줍니다. 해당 계획 노드의 실행을 위해 만들어진 플래너입니다. 추가 라인 노드의 요약 줄에서 들여쓰기되어 나타날 수 있습니다. 노드의 추가 속성입니다. 첫 번째 줄(요약 라인)에는 예상 총 실행 비용이 있습니다. 계획을 위해; 기획자가 원하는 것은 바로 이 숫자입니다. 최소화합니다.

다음은 출력이 어떻게 보이는지 보여주기 위한 간단한 예입니다. 좋아요:

젠 토토 선택 * FROM tenk1;

                         쿼리 계획
------------------------------------------------
 tenk1의 시퀀스 스캔(비용=0.00..458.00행=10000너비=244)

이 쿼리에는 다음이 없으므로어디에서절, 테이블의 모든 행을 스캔해야 하므로 플래너가 선택했습니다. 간단한 순차 스캔 계획을 사용합니다. 인용된 숫자 괄호 안은 (왼쪽에서 오른쪽으로):

• 예상 시작 비용. 이것은 그 전에 소비된 시간이다. 출력 단계가 시작될 수 있습니다(예: 정렬을 수행할 시간). 노드.

• 예상 총 비용. 이는 다음과 같은 가정하에 기술된다. 계획 노드가 완료될 때까지 실행됩니다. 즉, 사용 가능한 모든 행이 검색되었습니다. 실제로 노드의 상위 노드는 다음 단계에 도달하지 못할 수 있습니다. 사용 가능한 모든 행 읽기(참조제한아래 예).

• 이 계획 노드에 의해 출력된 예상 행 수입니다. 다시 말하지만, 노드는 완료될 때까지 실행되는 것으로 가정됩니다.

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

비용은 다음에 의해 결정된 임의의 단위로 측정됩니다. 기획자의 비용 매개변수(참조섹션 18.7.2). 전통적인 관행은 비용을 단위로 측정하는 것입니다. 디스크 페이지 가져오기; 즉,seq_page_cost이다 일반적으로 다음과 같이 설정됩니다.1.0그리고 다른 하나 비용 매개변수는 이에 맞춰 설정됩니다. 이 예는 섹션은 기본 비용 매개변수로 실행됩니다.

상위 수준의 비용이 노드에는 모든 하위 노드의 비용이 포함됩니다. 그것은 또한 중요하다 비용에는 기획자가 생각한 것만 반영된다는 사실을 깨닫기 위해 신경이 쓰인다. 특히 비용은 시간을 고려하지 않습니다. 결과 행을 클라이언트에 전송하는 데 소비되었습니다. 실제 경과 시간에 중요한 요소입니다. 하지만 기획자는 무시한다 왜냐하면 계획을 변경한다고 해서 그것을 바꿀 수는 없기 때문입니다. (모든 정답 계획은 동일한 행 집합을 출력할 것이라고 믿습니다.)

그행값이 조금 까다롭습니다. 왜냐하면 이는 처리되거나 스캔된 행의 수가 아니기 때문입니다. 계획 노드가 아니라 노드에서 내보낸 숫자입니다. 이것은 종종 필터링 결과 검색된 수보다 적음어디-조건이 되는 절 노드에 적용됩니다. 이상적으로 최상위 행 추정치는 실제로 반환, 업데이트 또는 행 수를 대략적으로 계산합니다. 쿼리에 의해 삭제되었습니다.

예로 돌아가기:

젠 토토 선택 * FROM tenk1;

                         쿼리 계획
------------------------------------------------
 tenk1의 시퀀스 스캔(비용=0.00..458.00행=10000너비=244)

이 숫자는 매우 간단하게 파생됩니다. 그렇게 한다면:

pg_class WHERE relname = 'tenk1'에서 relpages, reltuples 선택;

당신은 그것을 발견할 것입니다tenk1358개 있음 디스크 페이지 및 10000개 행. 예상 비용은 다음과 같이 계산됩니다(디스크 읽은 페이지 *seq_page_cost) + (스캔된 행 *cpu_tuple_cost). 기본적으로,seq_page_cost1.0이고cpu_tuple_cost은 0.01이므로 추정값은 비용은 (358 * 1.0) + (10000 * 0.01) = 458입니다.

이제 쿼리를 수정하여 다음을 추가하겠습니다.어디에서조건:

젠 토토 선택 * FROM tenk1 WHERE 고유1 < 7000;

                         쿼리 계획
----------------------------------
 tenk1의 시퀀스 스캔(비용=0.00..483.00행=7001너비=244)
   필터: (고유1 < 7000)

다음에 주목하세요.젠 토토출력 쇼어디다음으로 적용되는 절"필터"조건이 Seq에 첨부됨 스캔 계획 노드. 이는 계획 노드가 조건을 확인한다는 의미입니다. 각 행에 대해 스캔하고 통과한 행만 출력합니다. 조건. 출력 행의 추정치는 다음으로 인해 감소되었습니다.어디절. 그러나 스캔은 여전히 10000개의 행을 모두 방문해야 하므로 비용은 줄어들지 않습니다. 실제로는 조금 올랐습니다(10000 *cpu_operator_cost, 정확하게는) 확인에 소요된 추가 CPU 시간을 반영하기 위해어디에서조건.

이 쿼리가 선택하는 실제 행 수는 7000개이지만행추정치는 대략적인 수치일 뿐입니다. 만약에 이 실험을 재현하려고 하면 아마도 다음과 같은 결과를 얻게 될 것입니다. 약간 다른 추정치; 또한 매번 변경될 수 있습니다.분석명령, 왜냐하면 통계가 제작사분석다음에서 가져옴 테이블의 무작위 샘플입니다.

이제 조건을 더욱 제한적으로 만들어 보겠습니다.

젠 토토 선택 * FROM tenk1 WHERE 고유1 < 100;

                                  쿼리 계획
----------------------------------------------------
 tenk1의 비트맵 힙 스캔(비용=5.07..229.20행=101 너비=244)
   조건 재확인: (unique1 < 100)
   - tenk1_unique1의 비트맵 인덱스 스캔(비용=0.00..5.04행=101 너비=0)
         인덱스 조건: (unique1 < 100)

여기서 기획자는 2단계 계획을 사용하기로 결정했습니다. 계획 노드는 인덱스를 방문하여 일치하는 행의 위치를 찾습니다. 인덱스 조건을 가져온 다음 상위 계획 노드가 실제로 가져옵니다. 테이블 자체의 행입니다. 행을 별도로 가져오는 것은 많은 일입니다. 순차적으로 읽는 것보다 비용이 더 많이 들지만 전부는 아니기 때문에 테이블의 페이지를 방문해야 하지만 여전히 더 저렴합니다. 순차 스캔보다 (두 가지 계획 수준을 사용하는 이유는 상위 계획 노드는 다음으로 식별된 행 위치를 정렬합니다. 비용을 최소화하기 위해 읽기 전에 물리적 순서에 대한 색인을 작성합니다. 별도의 가져오기."비트맵"노드 이름에 언급된 것은 다음을 수행하는 메커니즘입니다. 정렬 중입니다.)

이제 다른 조건을 추가하겠습니다어디절:

젠 토토 선택 * FROM tenk1 WHERE Unique1 < 100 AND stringu1 = 'xxx';

                                  쿼리 계획
----------------------------------------------------
 tenk1의 비트맵 힙 스캔(비용=5.04..229.43행=1너비=244)
   조건 재확인: (unique1 < 100)
   필터: (stringu1 = 'xxx'::name)
   - tenk1_unique1의 비트맵 인덱스 스캔(비용=0.00..5.04행=101 너비=0)
         인덱스 조건: (unique1 < 100)

추가된 조건stringu1 = 'xxx'출력 행 수 추정치를 줄이지만 비용은 줄지 않습니다. 여전히 동일한 행 집합을 방문해야 합니다. 주의할 점은stringu1절은 다음으로 적용될 수 없습니다. 인덱스 조건(이 인덱스는에만 있기 때문에)고유1열. 대신에 필터로 적용됩니다. 인덱스로 검색된 행. 그래서 실제로 비용이 올랐어요 이 추가 검사를 약간 반영합니다.

어떤 경우에는 기획자가 다음을 선호할 것입니다."단순"색인 스캔 계획:

젠 토토 선택 * FROM tenk1 WHERE 고유1 = 42;

                                 쿼리 계획
----------------------------------------------------------------
 tenk1에서 tenk1_unique1을 사용하는 인덱스 스캔(비용=0.29..8.30행=1너비=244)
   인덱스 조건: (unique1 = 42)

이 유형의 계획에서는 테이블 행을 색인 순서로 가져옵니다. 그래서 읽기 비용이 더 많이 들지만, 너무 적습니다. 행 위치를 정렬하는 데 드는 추가 비용은 그만한 가치가 없습니다. 이 계획 유형은 쿼리만 가져오는 쿼리에 대해 가장 자주 표시됩니다. 단일 행. 또한 다음이 있는 쿼리에도 자주 사용됩니다.주문 기준색인과 일치하는 조건 순서를 충족하기 위해 추가 정렬 단계가 필요하지 않기 때문입니다.주문 기준.

여러 열에 별도의 색인이 있는 경우 에서 참조됨어디, 기획자는 아마도 인덱스의 AND 또는 OR 조합을 젠 토토하도록 선택하십시오.

젠 토토 선택 * FROM tenk1 여기서 고유1 < 100 AND 고유2  9000;

                                     쿼리 계획
------------------------------------------------------------------------
 tenk1의 비트맵 힙 스캔(비용=25.08..60.21행=10너비=244)
   조건을 다시 확인하세요: ((unique1 < 100) AND (unique2  9000))
   - BitmapAnd(비용=25.08..25.08행=10너비=0)
         - tenk1_unique1의 비트맵 인덱스 스캔(비용=0.00..5.04행=101 너비=0)
               지수 조건: (고유1 < 100)
         - tenk1_unique2의 비트맵 인덱스 스캔(비용=0.00..19.78행=999너비=0)
               지수 조건: (unique2  9000)

그러나 이를 위해서는 두 색인을 모두 방문해야 하므로 반드시 그럴 필요는 없습니다. 하나의 인덱스만 사용하고 다른 인덱스를 처리하는 것보다 유리합니다. 필터로서의 조건. 관련된 범위를 변경하면 다음과 같이 표시됩니다. 그에 따라 계획이 변경됩니다.

다음은 효과를 보여주는 예입니다제한:

젠 토토 선택 * FROM tenk1 여기서 고유1 < 100 AND 고유2  9000 LIMIT 2;

                                     쿼리 계획
------------------------------------------------------------------------
 제한(비용=0.29..14.48행=2너비=244)
   - tenk1에서 tenk1_unique2를 사용한 인덱스 스캔(비용=0.29..71.27행=10너비=244)
         인덱스 조건: (unique2  9000)
         필터: (고유1 < 100)

이것은 위와 동일한 쿼리이지만 다음을 추가했습니다.제한그래서 모든 행을 검색할 필요는 없습니다. 기획자는 무엇을 해야 할지에 대해 마음을 바꿨습니다. 주의할 점은 Index Scan 노드의 총 비용과 행 수가 다음과 같이 표시됩니다. 완료까지 실행되었습니다. 그러나 Limit 노드는 중지될 것으로 예상됩니다. 해당 행 중 5분의 1만 검색한 후이므로 총 비용은 다음과 같습니다. 5분의 1에 불과하며 이는 실제 예상 비용입니다. 쿼리. 이 계획은 Limit 노드를 추가하는 것보다 선호됩니다. 한도가 시작 비용을 피할 수 없었기 때문에 이전 계획 비트맵 스캔 비용이 발생하므로 총 비용은 그 이상일 것입니다. 해당 접근 방식을 사용하면 25개 단위입니다.

우리가 젠 토토한 열을 젠 토토하여 두 테이블을 결합해 보겠습니다. 논의 중:

젠 토토 선택 *
tenk1 t1, tenk2 t2에서
t1.unique1 < 10 AND t1.unique2 = t2.unique2;

                                      쿼리 계획
-------------------------------------------------------------------------
 중첩 루프(비용=4.65..118.62행=10너비=488)
   - tenk1 t1의 비트맵 힙 스캔(비용=4.36..39.47 행=10 너비=244)
         조건 재확인: (unique1 < 10)
         - tenk1_unique1의 비트맵 인덱스 스캔(비용=0.00..4.36행=10너비=0)
               지수 조건: (고유1 < 10)
   - tenk2 t2에서 tenk2_unique2를 사용한 인덱스 스캔(비용=0.29..7.91 행=1 너비=244)
         인덱스 조건: (unique2 = t1.unique2)

이 계획에는 두 개의 테이블이 있는 중첩 루프 조인 노드가 있습니다. 입력 또는 하위로 스캔합니다. 노드 요약의 들여쓰기 선은 계획 트리 구조를 반영합니다. 조인이 첫 번째이거나"외부", 자식은 유사한 비트맵 스캔입니다. 우리가 전에 본 사람들에게. 비용과 행 개수는 우리가 한 것과 동일합니다. 에서 얻다선택 ... 고유한 위치1 < 10우리는 다음을 적용하고 있기 때문에어디절고유1 < 10그 노드에서.t1.unique2 = t2.unique2절이 아님 아직 관련성이 있으므로 외부 스캔의 행 수에는 영향을 미치지 않습니다. 중첩 루프 조인 노드는 두 번째를 실행합니다. 또는"내부"자식은 다음에서 얻은 각 행에 대해 한 번씩 겉 아이. 현재 외부 행의 열 값은 다음과 같습니다. 내부 스캔에 연결되었습니다. 여기,t1.unique2바깥쪽 행의 값을 젠 토토할 수 있으므로 위에서 본 것과 유사한 계획과 비용을 얻습니다.선택 ... 어디서 t2.unique2 =상수케이스. (예상 비용은 실제로 위에서 본 것보다 약간 낮았습니다. 반복되는 인덱스 스캔 중에 발생할 것으로 예상되는 캐싱t2.) 루프 노드의 비용은 다음과 같습니다. 외부 스캔 비용과 1회 반복 비용을 기준으로 설정됩니다. 각 외부 행(여기서는 10 * 7.87)에 대한 내부 스캔과 조인 처리를 위한 CPU 시간이 거의 없습니다.

이 예에서 조인의 출력 행 개수는 다음과 같습니다. 두 스캔의 행 개수를 곱한 값이지만 모두 사실이 아닙니다. 경우가 더 있을 수 있기 때문입니다어디두 테이블을 모두 언급하는 절이므로 그렇게 할 수 있습니다. 두 입력 스캔에는 적용되지 않고 조인 포인트에만 적용됩니다. 여기 예:

젠 토토 선택 *
tenk1 t1, tenk2 t2에서
t1.unique1 < 10 AND t2.unique2 < 10 AND t1.hundred < t2.hundred;

                                         쿼리 계획
--------------------------------------------------------------------------------
 중첩 루프(비용=4.65..49.46행=33너비=488)
   조인 필터: (t1.hundred < t2.hundred)
   - tenk1 t1의 비트맵 힙 스캔(비용=4.36..39.47 행=10 너비=244)
         조건 재확인: (unique1 < 10)
         - tenk1_unique1의 비트맵 인덱스 스캔(비용=0.00..4.36행=10너비=0)
               지수 조건: (고유1 < 10)
   - 구체화(비용=0.29..8.51행=10너비=244)
         - tenk2 t2에서 tenk2_unique2를 사용한 인덱스 스캔(비용=0.29..8.46행=10너비=244)
               지수 조건: (unique2 < 10)

조건t1.백 < t2.백에서는 테스트할 수 없습니다.tenk2_unique2색인이므로 조인 시 적용됩니다. 노드. 이렇게 하면 조인 노드의 예상 출력 행 수가 줄어듭니다. 그러나 입력 스캔은 변경되지 않습니다.

여기서 기획자가 선택했음을 주목하세요"구체화하다"조인의 내부 관계, 그 위에 Materialise 계획 노드를 배치합니다. 이는 다음을 의미합니다.t2indexscan은 한 번만 수행됩니다. 중첩 루프 조인 노드는 해당 데이터를 10번 읽어야 하지만 외부 관계의 각 행에 대해 한 번씩. 구체화 노드 읽은 데이터를 메모리에 저장한 다음 데이터를 반환합니다. 각 후속 패스의 메모리에서.

외부 조인을 처리할 때 조인 계획 노드가 나타날 수 있습니다. 둘 다와 함께"결합 필터"그리고 일반"필터"조건이 첨부되었습니다. 가입 필터 조건은 외부 조인에서 나옵니다.켜짐절이므로 조인 필터에 실패한 행 조건은 여전히 null 확장 행으로 내보내질 수 있습니다. 하지만 일반 필터 조건은 외부 조인 규칙 이후에 적용됩니다. 무조건 행을 제거하는 역할을 합니다. 내부 조인에는 이러한 유형의 필터 간의 의미적 차이.

쿼리의 선택성을 약간 변경하면 매우 좋은 결과를 얻을 수 있습니다. 다른 가입 계획:

젠 토토 선택 *
tenk1 t1, tenk2 t2에서
t1.unique1 < 100 AND t1.unique2 = t2.unique2;

                                        쿼리 계획
-----------------------------------------------------------------------------
 해시 조인(비용=230.47..713.98행=101너비=488)
   해시 조건: (t2.unique2 = t1.unique2)
   - tenk2 t2의 시퀀스 스캔(비용=0.00..445.00 행=10000 너비=244)
   - 해시(비용=229.20..229.20행=101 너비=244)
         - tenk1 t1의 비트맵 힙 스캔(비용=5.07..229.20 행=101 너비=244)
               조건 재확인: (unique1 < 100)
               - tenk1_unique1의 비트맵 인덱스 스캔(비용=0.00..5.04행=101 너비=0)
                     인덱스 조건: (unique1 < 100)

여기서 플래너는 해시 조인을 사용하기로 선택했습니다. 하나의 테이블 중 하나가 메모리 내 해시 테이블에 입력된 후 다른 테이블을 스캔하고 해시 테이블에서 일치하는 항목을 검색합니다. 각 행에. 들여쓰기가 계획을 어떻게 반영하는지 다시 한번 살펴보세요. 구조: 비트맵 스캔 켜기텐크1이것은 해시 테이블을 구성하는 해시 노드에 대한 입력입니다. 그건 그런 다음 Hash Join 노드로 반환되어 해당 노드에서 행을 읽습니다. 외부 하위 계획을 수립하고 각각에 대한 해시 테이블을 검색합니다.

또 다른 가능한 조인 유형은 병합 조인입니다. 여기:

젠 토토 선택 *
tenk1 t1, onek t2에서
t1.unique1 < 100 AND t1.unique2 = t2.unique2;

                                        쿼리 계획
-----------------------------------------------------------------------------
 병합 조인(비용=198.11..268.19행=10너비=488)
   조건 병합: (t1.unique2 = t2.unique2)
   - tenk1 t1에서 tenk1_unique2를 사용한 인덱스 스캔(비용=0.29..656.28 행=101 너비=244)
         필터: (고유1 < 100)
   - 정렬(비용=197.83..200.33행=1000 너비=244)
         정렬 키: t2.unique2
         - onek t2의 시퀀스 스캔(비용=0.00..148.00 행=1000 너비=244)

병합 조인은 조인에서 입력 데이터를 정렬해야 합니다. 열쇠. 이 계획에서는tenk1데이터는 올바른 행을 방문하기 위해 인덱스 스캔을 젠 토토하여 정렬 순서가 있지만 순차 스캔 및 정렬이 선호됩니다.오네크, 방문할 행이 더 많기 때문입니다. 그 테이블에. (순차 스캔 및 정렬은 종종 인덱스를 능가합니다. 비순차적 디스크로 인해 많은 행을 정렬하기 위한 스캔 인덱스 스캔에 필요한 액세스입니다.)

변형 계획을 보는 한 가지 방법은 계획자가 강제로 가장 저렴하다고 생각되는 전략은 무시하고 활성화/비활성화 플래그는에 젠 토토되어 있습니다.섹션 18.7.1. (이것은 조잡한 도구이지만 유용합니다. 또한 참조하십시오.섹션 14.3.) 예를 들어, 순차 스캔 및 정렬이 처리하는 가장 좋은 방법이라는 확신이 없습니다. 테이블 포함오네크이전 예에서는 시도해 볼 수도 있어요

SET 활성화_정렬 = 꺼짐;

젠 토토 선택 *
tenk1 t1, onek t2에서
t1.unique1 < 100 AND t1.unique2 = t2.unique2;

                                        쿼리 계획
-----------------------------------------------------------------------------
 병합 조인(비용=0.56..292.65행=10너비=488)
   조건 병합: (t1.unique2 = t2.unique2)
   - tenk1 t1에서 tenk1_unique2를 사용한 인덱스 스캔(비용=0.29..656.28 행=101 너비=244)
         필터: (고유1 < 100)
   - onek t2에서 onek_unique2를 사용한 인덱스 스캔(비용=0.28..224.79 행=1000 너비=244)

플래너가 정렬을 생각하고 있음을 보여줍니다.오네크인덱스 스캔을 사용하면 약 12% 더 비쌉니다. 순차 스캔 및 정렬보다. 물론 다음 질문은 그게 맞는지. 우리는 다음을 사용하여 조사할 수 있습니다.분석 젠 토토, 아래에 젠 토토되어 있습니다.

14.1.2. 젠 토토하세요 분석

기획자의 추정치의 정확성을 확인할 수 있습니다 젠 토토하여젠 토토's분석옵션. 이 옵션을 젠 토토하면,젠 토토실제로 쿼리를 실행한 다음 내에 누적된 실제 행 수와 실제 런타임을 표시합니다. 각 계획 노드는 일반과 동일한 추정값과 함께젠 토토쇼. 예를 들어, 우리는 결과는 다음과 같습니다:

젠 토토 분석 선택 *
tenk1 t1, tenk2 t2에서
t1.unique1 < 10 AND t1.unique2 = t2.unique2;

                                                           쿼리 계획
---------------------------------------------------------------------------------------------------------------------------------
 중첩 루프(비용=4.65..118.62행=10 너비=488) (실제 시간=0.128..0.377행=10 루프=1)
   - tenk1 t1의 비트맵 힙 스캔(비용=4.36..39.47 행=10 너비=244) (실제 시간=0.057..0.121 행=10 루프=1)
         조건 재확인: (unique1 < 10)
         - tenk1_unique1의 비트맵 인덱스 스캔(비용=0.00..4.36행=10 너비=0)(실제 시간=0.024..0.024행=10 루프=1)
               지수 조건: (고유1 < 10)
   - tenk2 t2에서 tenk2_unique2를 사용한 인덱스 스캔(비용=0.29..7.91 행=1 너비=244) (실제 시간=0.021..0.022 행=1 루프=10)
         인덱스 조건: (unique2 = t1.unique2)
 총 런타임: 0.501ms

참고하세요"실제 시간"값 실시간의 밀리초 단위인 반면,비용추정치는 임의의 단위로 표현됩니다. 그래서 일치하지 않을 것 같습니다. 평소에 가장 많이 하는 일이 찾아야 할 중요한 것은 예상 행 수가 다음과 같은지 여부입니다. 합리적으로 현실에 가깝습니다. 이 예에서 추정치는 모두 하지만 실제로는 매우 이례적인 일입니다.

일부 쿼리 계획에서는 하위 계획 노드가 두 번 이상 실행되었습니다. 예를 들어, 내부 인덱스 스캔은 다음과 같습니다. 위의 중첩 루프 계획에서 외부 행당 한 번씩 실행됩니다. 그런 경우에는루프값은 합계를 보고합니다. 노드 실행 횟수, 실제 시간 및 행 표시된 값은 실행당 평균입니다. 이는 다음을 만들기 위해 수행됩니다. 비용 추정치가 표시되는 방식과 비슷한 수치입니다. 를 곱한다루프얻을 값 노드에서 실제로 소요된 총 시간입니다. 위의 예에서 우리는 인덱스 스캔을 실행하는 데 총 0.220밀리초가 소요되었습니다.tenk2.

어떤 경우에는분석 젠 토토쇼 계획 노드 실행 이외의 추가 실행 통계 시간 및 행 수. 예를 들어 정렬 및 해시 노드는 다음을 제공합니다. 추가 정보:

젠 토토 분석 선택 *
tenk1 t1, tenk2 t2에서
t1.unique1 < 100 AND t1.unique2 = t2.unique2 ORDER BY t1.fivethous;

                                                                 쿼리 계획
------------------------------------------------------------------------------------------------------------------
 정렬(비용=717.34..717.59 행=101 너비=488) (실제 시간=7.761..7.774 행=100 루프=1)
   정렬 키: t1.fivethous
   정렬 방법: 퀵소트 메모리: 77kB
   - 해시 조인(비용=230.47..713.98 행=101 너비=488) (실제 시간=0.711..7.427 행=100 루프=1)
         해시 조건: (t2.unique2 = t1.unique2)
         - tenk2 t2의 Seq 스캔(비용=0.00..445.00 행=10000 너비=244)(실제 시간=0.007..2.583 행=10000 루프=1)
         - 해시(비용=229.20..229.20 행=101 너비=244) (실제 시간=0.659..0.659 행=100 루프=1)
               버킷: 1024 배치: 1 메모리 사용량: 28kB
               - tenk1 t1의 비트맵 힙 스캔(비용=5.07..229.20 행=101 너비=244) (실제 시간=0.080..0.526 행=100 루프=1)
                     조건 재확인: (unique1 < 100)
                     - tenk1_unique1의 비트맵 인덱스 스캔(비용=0.00..5.04 행=101 너비=0)(실제 시간=0.049..0.049 행=100 루프=1)
                           지수 조건: (고유1 < 100)
 총 런타임: 8.008ms

정렬 노드는 젠 토토된 정렬 방법을 보여줍니다(특히, 정렬은 메모리 내 또는 디스크 내에서 수행됨) 및 메모리 또는 디스크의 양 필요한 공간. 해시 노드에는 해시 버킷 수와 해시에 젠 토토되는 최대 메모리 양과 배치 테이블. (배치 수가 1개를 초과하는 경우에도 마찬가지입니다. 디스크 공간 젠 토토량이 관련되어 있지만 표시되지 않습니다.)

또 다른 유형의 추가 정보는 제거된 행 수입니다 필터 조건으로:

젠 토토 분석 선택 * FROM tenk1 WHERE ten < 7;

                                               쿼리 계획
-------------------------------------------------------------------------------
 tenk1의 Seq 스캔(비용=0.00..483.00 행=7000 너비=244)(실제 시간=0.016..5.107 행=7000 루프=1)
   필터: (10 < 7)
   필터에 의해 제거된 행: 3000
 총 런타임: 5.905ms

이러한 수는 필터 조건에 특히 유용할 수 있습니다. 조인 노드에 적용됩니다."행 삭제됨"행은 최소한 하나의 행을 스캔한 경우에만 나타납니다. 또는 조인 노드의 경우 잠재적인 조인 쌍이 거부됩니다. 필터 조건.

필터 조건과 유사한 경우가 발생합니다."손실"색인 스캔. 예를 들어, 다음을 고려해보세요 특정 지점을 포함하는 다각형 검색:

젠 토토 분석 선택 * FROM 다각형_tbl WHERE f1 @ 다각형 '(0.5,2.0)';

                                              쿼리 계획
----------------------------------------------------------------------------
 Polygon_tbl의 시퀀스 스캔(비용=0.00..1.05행=1 너비=32)(실제 시간=0.044..0.044행=0 루프=1)
   필터: (f1 @ '((0.5,2))'::폴리곤)
   필터에 의해 제거된 행: 4
 총 런타임: 0.083ms

기획자는 이 샘플 테이블이 다음과 같다고 (아주 정확하게) 생각합니다. 인덱스 스캔을 하기에는 너무 작기 때문에 우리는 일반 필터에 의해 모든 행이 거부되는 순차 스캔 조건. 그러나 인덱스 스캔을 강제로 사용하면 다음과 같은 결과가 나타납니다.

설정 활성화_seqscan 꺼짐;

젠 토토 분석 선택 * FROM 폴리곤_tbl WHERE f1 @ 폴리곤 '(0.5,2.0)';

                                                        쿼리 계획
------------------------------------------------------------------------------------------------
 Polygon_tbl에서 gpolygonind를 사용한 인덱스 스캔(비용=0.13..8.15행=1 너비=32)(실제 시간=0.062..0.062행=0 루프=1)
   인덱스 조건: (f1 @ '((0.5,2))'::폴리곤)
   인덱스 재검사로 제거된 행: 1
 총 런타임: 0.144ms

여기서 우리는 색인이 하나의 후보 행을 반환했음을 볼 수 있습니다. 그런 다음 인덱스 조건을 다시 확인하여 거부되었습니다. 이런 일이 일어난다 GiST 인덱스는 다음과 같습니다."손실"용 다각형 포함 테스트: 실제로 다음과 같은 행을 반환합니다. 대상과 겹치는 다각형을 만든 다음 정확한 작업을 수행해야 합니다. 해당 행에 대한 격리 테스트입니다.

젠 토토다음이 있습니다버퍼함께 젠 토토할 수 있는 옵션분석더 많은 런타임 통계를 얻으려면:

젠 토토(분석, 버퍼) SELECT * FROM tenk1 WHERE 고유1 < 100 AND 고유2  9000;

                                                           쿼리 계획
---------------------------------------------------------------------------------------------------------------------------------
 tenk1의 비트맵 힙 스캔(비용=25.08..60.21 행=10 너비=244)(실제 시간=0.323..0.342 행=10 루프=1)
   조건을 다시 확인하세요: ((unique1 < 100) AND (unique2  9000))
   버퍼: 공유 히트=15
   - BitmapAnd(비용=25.08..25.08행=10 너비=0)(실제 시간=0.309..0.309행=0 루프=1)
         버퍼: 공유 적중=7
         - tenk1_unique1의 비트맵 인덱스 스캔(비용=0.00..5.04 행=101 너비=0)(실제 시간=0.043..0.043 행=100 루프=1)
               지수 조건: (고유1 < 100)
               버퍼: 공유 적중=2
         - tenk1_unique2의 비트맵 인덱스 스캔(비용=0.00..19.78행=999너비=0)(실제 시간=0.227..0.227행=999루프=1)
               인덱스 조건: (unique2  9000)
               버퍼: 공유 적중=5
 총 런타임: 0.423ms

제공된 숫자버퍼도움말 쿼리의 어느 부분이 가장 I/O 집약적인지 식별합니다.

이것을 명심하세요 왜냐하면젠 토토하세요 분석실제로 쿼리를 실행하면 부작용이 발생합니다. 평소와 같이 쿼리가 출력할 수 있는 결과가 무엇이든 간에 인쇄를 위해 폐기됨젠 토토데이터. 데이터 수정 쿼리를 분석하지 않고 분석하려는 경우 테이블을 변경하면 나중에 명령을 롤백할 수 있습니다. 예:

시작;

젠 토토 분석 업데이트 tenk1 SET 100 = 100 + 1 여기서 고유 1 < 100;

                                                           쿼리 계획
--------------------------------------------------------------------------------------------------------------------------------
 tenk1 업데이트(비용=5.07..229.46행=101 너비=250)(실제 시간=14.628..14.628행=0 루프=1)
   - tenk1의 비트맵 힙 스캔(비용=5.07..229.46행=101 너비=250)(실제 시간=0.101..0.439행=100루프=1)
         조건 재확인: (unique1 < 100)
         - tenk1_unique1의 비트맵 인덱스 스캔(비용=0.00..5.04 행=101 너비=0)(실제 시간=0.043..0.043 행=100 루프=1)
               지수 조건: (고유1 < 100)
 총 런타임: 14.727ms

롤백;

이 예에서 볼 수 있듯이 쿼리는 다음과 같습니다.삽입, 업데이트또는삭제명령, 실제 작업 테이블 변경 사항 적용은 최상위 수준의 삽입, 업데이트, 또는 계획 노드를 삭제합니다. 이 노드 아래의 계획 노드는 다음을 수행합니다. 이전 행을 찾거나 새 데이터를 계산하는 작업입니다. 그래서 위에서 본 것과 동일한 종류의 비트맵 테이블 스캔을 볼 수 있습니다. 이미 있고 그 출력은 업데이트를 저장하는 업데이트 노드에 공급됩니다. 행이 업데이트되었습니다. 데이터를 수정하더라도 주목할 가치가 있습니다. 노드는 상당한 양의 런타임이 걸릴 수 있습니다(여기서는 대부분의 시간을 소비하지만) 계획자는 그렇지 않습니다. 현재 이를 고려하여 비용 견적에 무엇이든 추가하세요. 일. 모든 사람이 해야 할 일은 동일하기 때문입니다. 올바른 쿼리 계획이므로 계획 결정에 영향을 미치지 않습니다.

그총 런타임표시자:분석 젠 토토실행기 시작 및 종료 시간 및 트리거를 실행하는 시간 해고되지만 구문 분석, 재작성 또는 계획은 포함되지 않습니다. 시간. 실행에 소요된 시간이전트리거가 있는 경우 관련 삽입 시간에 포함됩니다. 노드 업데이트 또는 삭제 하지만 실행에 소요된 시간이후트리거는 거기에 포함되지 않습니다. 왜냐하면이후완료 후 트리거가 실행됩니다. 전체 계획 중. 각 트리거에 소요된 총 시간(둘 중 하나)이전또는이후) 도 별도로 표시됩니다. 지연된 제약 조건이 트리거된다는 점에 유의하세요. 트랜잭션이 끝날 때까지 실행되지 않으므로 실행되지 않습니다. 전혀 표시되지 않음분석 젠 토토.

14.1.3. 주의사항

런타임을 측정하는 두 가지 중요한 방법이 있습니다.분석 젠 토토정상에서 벗어날 수 있음 동일한 쿼리를 실행합니다. 첫째, 출력 행이 없기 때문에 클라이언트에게 전달되는 네트워크 전송 비용 및 I/O 전환 비용은 포함되지 않습니다. 둘째, 측정 오버헤드 님이 추가함분석 젠 토토될 수 있습니다 특히 느린 컴퓨터에서는 중요합니다.gettimeofday()운영 체제 호출. 당신은 할 수 있습니다 젠 토토하다젠 토토 : 문서 : 9.3측정 도구 시스템의 타이밍 오버헤드.

젠 토토결과는 다음과 같아서는 안 됩니다. 당신과 많이 다른 상황으로 추정됩니다. 실제로 테스트 중입니다. 예를 들어, 장난감 크기 테이블의 결과는 큰 테이블에 적용되는 것으로 가정됩니다. 기획자의 비용 추정 선형적이지 않으므로 더 큰 규모의 경우 다른 계획을 선택할 수 있습니다. 또는 작은 테이블. 극단적인 예는 테이블에만 있는 경우입니다. 하나의 디스크 페이지를 차지하므로 거의 항상 순차 스캔을 받게 됩니다. 인덱스를 사용할 수 있는지 여부를 계획합니다. 기획자는 깨닫는다 테이블을 처리하는 데 하나의 디스크 페이지를 읽어야 한다는 것입니다. 어쨌든 추가 페이지 읽기를 확장하는 것은 가치가 없습니다. 지수를 보세요. (우리는 이런 일이 일어나는 것을 보았습니다.polygon_tbl위의 예.)

실제값과 추정값이 일치하지 않는 경우가 있습니다. 잘 일치하지만 실제로 잘못된 것은 없습니다. 이런 경우가 하나 발생합니다 계획 노드 실행이 a에 의해 중단되는 경우제한또는 유사한 효과. 예를 들어,제한이전에 사용했던 쿼리

젠 토토 분석 선택 * FROM tenk1 여기서 고유1 < 100 AND 고유2  9000 제한 2;

                                                          쿼리 계획
-----------------------------------------------------------------------------------------------------
 제한(비용=0.29..14.71행=2너비=244)(실제 시간=0.177..0.249행=2루프=1)
   - tenk1에서 tenk1_unique2를 사용한 인덱스 스캔(비용=0.29..72.42 행=10 너비=244) (실제 시간=0.174..0.244 행=2 루프=1)
         인덱스 조건: (unique2  9000)
         필터: (고유1 < 100)
         필터에 의해 제거된 행: 287
 총 런타임: 0.336ms

인덱스 스캔 노드의 예상 비용 및 행 수는 다음과 같습니다. 마치 실행이 완료된 것처럼 표시됩니다. 그러나 실제로는 한계 노드가 두 개를 얻은 후 행 요청을 중지했으므로 실제 행은 개수가 2개에 불과하고 실행 시간이 예상 비용보다 작습니다. 제안할 것입니다. 이는 추정 오류가 아니라 불일치일 뿐입니다. 추정치와 실제 값이 표시되는 방식입니다.

병합 조인에는 또한 혼란을 야기할 수 있는 측정 아티팩트가 있습니다. 부주의하다. 병합 조인은 하나의 입력이 소진되면 읽기를 중지합니다. 다른 입력과 한 입력의 다음 키 값이 더 큽니다. 다른 입력의 마지막 키 값보다; 그런 경우에는 거기에 더 이상 일치하는 항목이 없으므로 첫 번째 항목의 나머지 부분을 스캔할 필요가 없습니다. 입력. 이로 인해 한 아이의 내용을 모두 읽지 못하게 되고, 언급된 것과 같은제한. 또한 만약에 외부(첫 번째) 하위 항목에는 중복된 키 값이 있는 행이 포함되어 있습니다. 내부(두 번째) 하위 항목이 백업되고 해당 부분에 대해 다시 검색됩니다. 해당 키 값과 일치하는 행 중젠 토토하세요 분석동일한 내부 행의 반복된 방출을 계산합니다. 마치 실제 추가 행인 것처럼 말이죠. 외부인이 많을 때 중복, 내부 하위 계획에 대해 보고된 실제 행 수 노드는 행 수보다 훨씬 클 수 있습니다. 실제로 내부 관계에 있습니다.

BitmapAnd 및 BitmapOr 노드는 항상 실제 행을 보고합니다. 구현 제한으로 인해 0으로 계산됩니다.