query 튜닝 대량 데이터 hash_join 유도후 다시 급격히 느려짐.

기존 쿼리 속도가 느려서 체크해보니. join들이 index_join을 하고있지만 대량 조인(배치)라 속도가 느려짐.

 

set local enable_mergejoin = false;

set local enable_nestloop = false;

설정을 하여 hash_join을 유도해 속도를 1초까지 단축시킴 . 하지만 어느순간 갑자기 속도가 10초이상으로 느려짐..

 

Planning Time: 23.284 ms
JIT:
  Functions: 1001
  Options: Inlining true, Optimization true, Expressions true, Deforming true
  Timing: Generation 68.033 ms, Inlining 823.403 ms, Optimization 5257.604 ms, Emission 3780.375 ms, Total 9929.415 ms
Execution Time: 10531.990 ms

 

 

위는 결과임

 

해당 결과를 보면 실행 시간은 10531 이지만 jit total은 9929임 즉 , jit에서 90프로이상 시간을 잡아먹고있는거임.

 

이건 현재 jit가 동작해서 속도가 느려졌다고 판단할수있음.

 

JIT(Just-In-Time compilation) 은 PostgreSQL 11부터 도입된 기능으로, 쿼리 실행 중 반복 계산을 더 빠르게 하기 위해 CPU 수준의 머신 코드로 변환(컴파일)하는 최적화 기술.


. JIT이 뭔지부터

PostgreSQL은 기본적으로 인터프리터 방식으로 쿼리를 실행합니다.

예: “이 행의 a+b를 계산해라” → C 코드 내부에서 함수 호출로 매번 계산. 행이 수백만 건이면 이 함수 호출을 수백만 번 반복합니다.

그런데 JIT(Just-In-Time Compilation) 은 이렇게 안 하고,

“어차피 같은 연산을 수백만 번 반복할 거라면…” → 실행 중에 아예 그 연산만 하는 CPU 머신코드를 만들어서 컴파일합니다. 그러면 실행할 때는 함수 호출이 아니라 CPU에서 바로 곱셈/덧셈 명령이 실행됩니다.

👉 장점: 반복이 아주 많으면 빠르다. 👉 단점: 그 코드를 만드는 과정(컴파일) 이 시간이 걸린다.

 

 

2. 왜 시간이 다 JIT에서 날아갔나?

이번 쿼리는 “해시 전용”으로 막혀 있었죠.

• 해시 조인은 큰 테이블 전체를 스캔해서 메모리에 담은 뒤, 조인 키를 비교합니다.
• 이런 계획은 “비용이 엄청 클 것” 이라고 플래너가 추정합니다.
• PostgreSQL은 비용이 일정 기준(jit_above_cost)을 넘으면
  → JIT을 최적화 풀옵션(인라이닝, 코드 최적화 등)으로 켜버립니다.

즉, PostgreSQL이 이렇게 생각한 겁니다:

“이거 몇 천만 번 계산할 거 같은데? 컴파일해두면 빨라지겠지!”

그런데 실제론,

• 해시 조인이라 계산식이 복잡하긴 하지만 반복 횟수가 그렇게 많지 않았음
• 컴파일 준비(코드 생성 + 인라이닝 + 최적화)가 거의 10초 걸렸음
• 실제 실행은 0.5초 정도밖에 안 걸렸음

👉 즉, **“총알은 1발 쏘려고 총기를 새로 설계·제작한 셈”**이라서, 실행보다 준비가 훨씬 오래 걸린 거예요.

---

3. 조금 더 친숙한 비유

• 인터프리터 모드 = 주판으로 매번 손으로 더하기. 느리지만 준비는 필요 없음.
• JIT 모드 = 전용 계산기를 직접 설계하고 칩을 만들고 나서 사용.
  • 수십억 번 쓸 거면 유리.
  • 단 100번만 쓸 거라면, 계산기 만드는 시간만 날리는 꼴.

이번 해시 전용 플랜은 **“100번밖에 안 쓸 문제인데 계산기부터 만든 상황”**입니다.

---

4. 그래서 정리하면

• PostgreSQL은 쿼리가 복잡하고 크다고 생각 → JIT 풀옵션 발동.
• JIT 컴파일(코드 생성·최적화)에 9.9초 소요.
• 실제 쿼리 실행은 0.6초밖에 안 걸렸음.
• → 전체 10.5초 중 대부분을 JIT이 먹은 것.