실행 순서입니다. 

1) t1 풀스캔(seq scan) 
2) t3 인덱스 스캔( t3_idx01) 
3) nl 조인(t1, t3) 
4) t2 인덱스 스캔( t2_idx01) 
5) nl조인( 3)의 결과와 t2 )  

조인 순서는 
t1 --> t3 --> t2 

드라이빙 테이블은 t1 입니다.

nl 조인의 경우 오라클과 동일하지만, 

hash 조인의 경우는 오라클과 해석법이 틀립니다. (반대임) 

 

 t1이랑 t2가 먼저 만나서 그 결과를 가지고, t3에서 찾을 수도 있어요. 

그런데, 여기서는 t1이랑 t3가 먼저 만났네요. 

이유는 실행계획기만 알겠죠. 

보통 이렇게 사람의 상식과 다르게 계획을 짤때는 그 나름의 이유가 있어서입니다. 

이유가 없다면, 정말 그 때 그때의 운이기도 하고요. 

그 나름의 이유는 대부분 해당 테이블의 자료분포를 저장하는 통계정보 때문입니다. 

generate_series 함수를 이용해서 자료를 입력한 뒤, 정상적으로 해당 테이블의 통계정보를 수집했다면, 

모든 테이블의 c1 칼럼에 대한 자료 분포는 아주 고르다고 판단하겠죠. 

이런경우라는 c1,c2 를 join 비용이나, c1, c3 join 비용이나 다 같겠네요. 

그런데, 무슨 이유에 의해서인지는 모르겠지만, pg의 최적화기는 c1, c3 를 먼저 선택했네요. 

아마도 다중 join 에서 이런 방식 (처음과 끝 테이블을 먼저 처리한다)이 보다 합리적인 방식이다고 판단한 것 같습니다. 

옵티마이져 짠 사람에게 물어봐야 정확한 설명을 들을 수 있을 것 같습니다. 

여튼 실세계내에 정말 저런 형태의 자료라면 저라면, t2_idx01 인덱스를 없애, t1,t2를 해시로 만들고 그걸 t3의 nested로 풀것 같습니다. 

그렇게 하면, 아마 최적화는 t1,t3 nested를 먼저하고, 그걸로 t2랑 해시 조인을 할 수도 있겠군요. 안해봐서 모르겠습니다.

pgadmin 툴을 사용하신다면

F7 누르시고 하단의 EXPLAIN 탭에서 첫번째 Graphical  을 보시면 시각적으로 표현해 줍니다.