자료가 많으면 성능이 떨어지는 것은 당연한데, 

그 원인이 어디 있느냐를 밝혀야 성능을 높일 수 있는 방법을 찾을 수 있겠죠. 

참 원론적인 이야기입니다. 

select 하는 row수가 항상 일정하고 그 쿼리가 인덱스를 사용하다면, 자료량이 많아질수록, 

비용이 소요되는 부분은 해당 자료의 인덱스에서 자료를 찾는 비용만 커져야 합니다. 

그런데, 자료량이 많아지면서 같은 row수의 자료를 추출하기 위해 읽는 데이터블럭 수가 

점점 많아진다면, 성능은 눈에 띄게 떨어지겠죠. 

이런 경우라면, 쿼리 튜닝으로 문제를 풀어야할 것 같고요. 

깔끔한 쿼리 튜닝에도 불구하고, 성능이 떨어진다면, 이 때부터는 상황이 조금 복잡해집니다. 

어떤 부분이 성능을 떨어지게 하는지 찾아야하니까요. 

일반적으로 동일 쿼리에 동일 자료량 임에도 불구하고 성능이 떨어지는 경우는 

크게 하드웨어적인 문제와, OS 부분과, 서버 환경 설정 부분으로 나눠서 생각해 봐야하는데, 

DB 입장에서만 보면, 

• lock (pg_locks 로 살펴봅니다)
• data block buffer cache (pg_buffercache, pg_statio_user_” 로 봅니다)
• 다른 프로세스의 간섭 (체크포인트, autovacuum, stat collector, bgwriter, 다른 세션) (pg_stat_bgwriter와, pg_stat_activity로 봅니다)

한 방에 쉽게 DB 서버 자기가 자기 자신을 분석하고, 자기가 해결책을 찾을 수 있다면, 

얼마나 좋을까 이런 생각을 잠시 해보네요. 

차근하게 처음 접하는 이들에게는 

일단 explain 으로 성능 좋을 때와, 성능 나쁠 때의 실행계획이 어떻게 틀린지 살펴보는 것부터 

하는 것이 제일 빠른 길 같네요.

항상 관심갖아주셔서 감사합니다. 덕분에 여러 어려움을 많이 해결할 수 있었습니다.

말씀하신대로 쿼리 부분을 우선 봐야될 것 같습니다.

즐거운 하루 되시길 바랍니다. 감사합니다.