PostgreSQL, SSD 환경에서 random_page_cost 설정은 어떻게 해야 할까?

게시물에서는 PostgreSQL의 random_page_cost 기본값(4.0)이 최신 SSD 환경에서 과소평가될 수 있음을 지적하며, 실험을 통해 이를 검증한다. 실험 결과, 로컬 SSD 환경에서는 random I/O 비용이 25~35 수준으로, 원격 SSD 환경에서는 더 높은 값을 보였다. 이는 쿼리 플래너가 잘못된 실행 계획을 선택하게 하여 성능 저하(Performance Degradation)를 유발할 수 있음을 시사한다.

게시물은 random_page_cost의 부정확한 설정이 쿼리 플래너의 판단에 영향을 미쳐, 부적절한 실행 계획을 선택하게 될 수 있다고 분석한다. 특히, 인덱스 스캔(Index Scan)과 시퀀셜 스캔(Sequential Scan) 간의 선택에서 selectivity에 따라 잘못된 계획이 선택될 경우, 쿼리 성능이 최대 10배까지 저하될 수 있다고 경고한다. 이는 데이터베이스 시스템의 성능 튜닝(Performance Tuning)에 있어 정확한 비용 모델링의 중요성을 강조한다.

게시물은 비트맵 스캔(Bitmap Scan)이 인덱스 스캔보다 더 나은 성능을 보이며, prefetching을 통해 I/O 성능을 향상시킬 수 있다고 설명한다. 특히, prefetching은 I/O를 미리 수행하여 지연 시간(Latency)을 줄이는 효과가 있지만, 현재 PostgreSQL의 비용 모델에는 prefetching의 영향이 제대로 반영되지 않고 있다. 이는 향후 비용 모델 개선(Cost Model Improvement)의 필요성을 제기한다.

게시물은 random_page_cost를 낮추는 것이 항상 정답은 아니라고 강조하며, 캐싱(Caching)의 중요성을 언급한다. 데이터가 캐시에 적중하는 경우, random I/O가 오히려 더 효율적일 수 있으며, 쿼리 플래너가 이러한 상황을 정확히 예측하기 어렵다는 점을 지적한다. 따라서, random_page_cost 조정은 시스템의 특성과 쿼리 패턴을 고려하여 신중하게 접근해야 한다.

게시물은 prefetching을 비용 모델에 반영하고, 캐싱된 데이터에 대한 통계 정보를 개선하는 것이 PostgreSQL 성능 향상의 핵심 과제라고 제시한다. 또한, random_page_cost와 관련된 다양한 추가 오버헤드를 별도의 GUC 파라미터로 분리하는 방안을 제안한다. 이러한 개선을 통해 PostgreSQL은 SSD 환경에서 더욱 효율적인 쿼리 실행 계획을 수립하고, 전반적인 성능 최적화(Performance Optimization)를 달성할 수 있을 것이다.