SQL Server, MySQL , PostgreSQL 플랜캐시

공부하면서 알게된 내부적인 차이점에 대해 기록해보자
1. 플랜캐시 여부
SQL Server: 구문별 실행계획을 플랜캐시 영역에 저장한다. 이는 다른 세션에서도 함께 사용이 가능하며 통계 업데이트, DDL 등의 변경 사항, 플랜 캐시 영역의 공간 부족이 없을 경우 유지가 된다.

PostgreSQL : 실행 계획을 전체가 공유하는 메모리 영역은 존재하지 않는다. 다만 세션별로 실행 계획을 보유하고 있을 수 있으며 이를 활용하기 위해서는 Prepare Statement 를 사용하여 호출을 하여야 한다. PostgreSQL은 SQL 구문 분석부터 시작하는 하드 파싱과 이전 실행계획을 검색하고 사용하는 소프트 파싱이 존재하며 Prepare 는 소프트 파싱을 사용할 수 있다. pg는 plan tree가 아닌 재작성된 쿼리 tree를 저장하여 최적화 단계는 진행되는데 이로인해 매번 최적화의 소요시간이 생기는 단점이 있지만 파라미터 스니핑 같은 단점은 해소가 된다.  Prepare의 동작은 Prepared 단계와 Execute 단계로 나누어지고 하단의 그림에서 보이는 것 처럼 Prepare단계에서 실행계획을 생성 및 저장하고 Execute 단계는 해당 실행 계획을 사용하여 쿼리를 실행한다 prepareThreshold 변수 값에 따라 특정 횟수 이후부터 플랜 캐시를 사용한다.
 

prepare stmt1(char) as select count(*) from t1 where c1=$1;

execute stmt1('T')

 
 
MySQL : PostgreSQL과 비슷하다. SP와 Prepared Statement 로 호출되는 경우 동일 세션에서는 파싱 영역을 캐시처리하여 성능 향상을 기대할 수 있다.
 
 
 
 
 
 
참고 :
postgreSQL 9.6 성능이야기 - 시연아카데미
https://dev.mysql.com/doc/refman/8.0/en/statement-caching.html
https://yechankk.tistory.com/25
https://sonhyunwoong.tistory.com/64
https://vladmihalcea.com/postgresql-jdbc-statement-caching/
https://p829911.tistory.com/11