피드로 돌아가기
Dev.toDatabase
원문 읽기
Simple vs Extended 프로토콜을 통한 Query Plan 재사용 및 Network Round-trip 최적화
1.1.2 Simple vs Extended
AI 요약
Context
단일 메시지로 처리되는 Simple Query 프로토콜의 반복적 Parse/Analyze 단계로 인한 CPU 오버헤드 발생. 특히 대량의 파라미터화된 쿼리 실행 시 매번 발생하는 Planning 비용이 시스템 병목 지점으로 작용.
Technical Solution
- Parse('P'), Bind('B'), Execute('E'), Sync('S')로 쿼리 라이프사이클을 분리한 Extended 프로토콜 설계
- SQL 템플릿을 CachedPlanSource에 저장하여 Parse/Analyze 단계를 생략하는 Prepared Statement 도입
- 데이터 분포의 왜곡(Skewed Distribution) 대응을 위해 Custom Plan과 Generic Plan을 동적으로 선택하는 choose_custom_plan() 로직 구현
- 초기 5회 실행까지 Custom Plan을 생성하여 실제 비용을 측정하고, 6회차부터 Generic Plan의 비용과 비교하여 최적 경로를 결정하는 비대칭적 비교 전략 채택
- libpq pipeline mode 및 JDBC batch 처리로 다수 쿼리를 단일 Round-trip으로 통합하여 네트워크 레이턴시 제거
- plan_cache_mode GUC 설정을 통해 워크로드 특성에 따라 Generic/Custom Plan 강제 지정 가능 구조 설계
실천 포인트
- 대량 INSERT/UPDATE 시 Prepared Statement를 통한 Parse 단계 제거 여부 확인 - 데이터 분포가 불균형한 컬럼 조회 시 Generic Plan 강제로 인한 성능 저하 가능성 검토 - PgBouncer Transaction Pooling 사용 환경에서 Prepared Statement의 짧은 생명주기로 인한 Plan Caching 효율 저하 분석 - Cross-region RDS 등 네트워크 레이턴시가 높은 환경에서 Pipelining 적용 및 Sync 메시지 기반 에러 핸들링 설계