[CBRD-26475] hash join 실행계획을 옵티마이저가 선택

[shparkcubrid]

http://jira.cubrid.org/browse/CBRD-26475

Purpose

9.2 버전에서는 옵티마이저가 Sort Merge Join을 선택하지 못하도록 변경되었다. 이전 이슈를 확인해 보면, Nested Loop Join을 선택해야 할 질의에서 Sort Merge Join이 선택되면서 성능 저하가 발생했고, 이로 인해 장애로 이어진 사례가 있었다. 당시에는 정확한 원인을 파악하지 못한 채 전반적으로 Sort Merge Join을 비활성화한 것으로 보인다. 추정컨대, 통계 정보 기반 estimation 오류로 인해 시간이 지남에 따라 선택도가 실제보다 낮게 평가되었고, 그 결과 옵티마이저가 조인 대상 데이터가 적다고 잘못 판단하여 Sort Merge Join을 선택했을 가능성이 있다. 현재는 이러한 부정확한 estimation 관련 로직이 모두 제거되었다. 이에 따라 Sort Merge Join과 Hash Join을 옵티마이저가 다시 선택할 수 있도록 수정한다.

Implementation

USE_HASH 힌트 없이도 옵티마이저는 hash join을 선택한다.
Sort Merge Join은 hash join 대비 성능상의 이점이 없으므로, 기존과 동일하게 힌트 사용이나 파라미터 변경이 있는 경우에만 선택한다.

hash join cost 계산 공식

  cpu_cost = (inner_cardinality * CPU_WEIGHT * HJ_BUILD_CPU_OVERHEAD_FACTOR);
  cpu_cost += (outer_cardinality * CPU_WEIGHT * HJ_PROBE_CPU_OVERHEAD_FACTOR);
  cpu_cost += HJ_MEM_ALLOC_CONSTANT; <== 초기 메모리 생성 상수 비용 (적은 데이터는 nl조인을 우선하기 위해 사용)
  io_cost = inner_pages;

Remarks

예상 페이지 수를 산정하는 데 사용되는 projected_size가 잘못 계산되어 이를 수정했다.

varchar와 같은 가변 길이 타입의 경우 0으로 잘못 예측되던 문제를 해결하고, 적절한 길이를 기준으로 예측하도록 개선했다.

[shparkcubrid]

/run medium, sql

[shparkcubrid]

/run all

[shparkcubrid]

/run all