plan_cache_mode
| 버전 | 기본값 | context | 타입 |
|---|---|---|---|
| 14 | — | user | enum |
| 15 | — | user | enum |
| 16 | — | user | enum |
| 17 | — | user | enum |
| 18 | — | user | enum |
| 19 | — | user | enum |
prepared statement를 실행할 때 custom plan과 generic plan 중 무엇을 쓸지에 대한 planner의 자동 선택을 강제로 덮어쓴다. 허용 값은 auto(기본값), force_custom_plan, force_generic_plan이다.
명시적으로 PREPARE한 것이든 PL/pgSQL 등이 내부적으로 만드는 것이든, prepared statement는 두 방식으로 실행될 수 있다. custom plan은 실행할 때마다 그 시점의 파라미터 값을 반영해 새로 planning하고, generic plan은 파라미터 값에 의존하지 않게 만들어 실행 간에 재사용한다. generic plan은 planning 비용을 아끼지만, 이상적인 plan이 파라미터 값에 크게 좌우되는 쿼리 — 값 분포가 심하게 치우친 컬럼을 조건으로 거는 경우가 대표적이다 — 에서는 비효율적일 수 있다.
auto에서는 처음 다섯 번의 실행에 custom plan을 쓰면서 평균 비용을 기록하고, 그 이후 generic plan의 추정 비용이 custom plan 평균 비용(planning 비용 가산)보다 유리하다고 판단되면 generic plan으로 전환한다. 이 설정은 cached plan을 실행하는 시점에 평가되며, PREPARE 시점에는 영향을 주지 않는다. 따라서 세션 도중 값을 바꾸면 이미 준비된 statement의 실행 방식도 바뀐다.
force_custom_plan은 항상 파라미터 값 기준으로 planning하게 하고, force_generic_plan은 항상 generic plan을 쓰게 한다. 전자는 generic plan 전환 후 특정 파라미터 값에서 plan이 나빠지는 문제를 피할 때, 후자는 planning 비용이 부담인 단순 반복 쿼리에서 planning을 확실히 생략할 때 쓴다.
auto의 generic plan 전환이 원인이다. EXPLAIN EXECUTE 출력에서 조건에 $1 같은 파라미터 심볼이 그대로 남아 있으면 generic plan이다. 문제가 되는 세션이나 함수 단위로 SET plan_cache_mode = force_custom_plan을 적용해 원인인지 확인한다.출처: PostgreSQL 18 문서