느린 쿼리들을 추출하여 explain을 확인하셔야할듯 합니다.

pg_badger 등을 이용하시면 좋으시고..

disk i/o가 적게 발생하도록 튜닝을 하셔야할듯 합니다.

 네 감사합니다. 

우선 플랜으로 봤을때는 문제가 될만한 상황은 아닌것 같습니다.

같은 프로시져를 실행하는데 100번 실행 하는데 90번은 매우 빠르게 실행이 되는데.

10번이 느린 경우가 발생됩니다. 계속 느린다고 하면 이해가 되는데. 데이터량은 1~2건 정도 이므로 이해가 되지 않습니다. 우선 DB 에서 실행 되는 시간을 찾아봐야겠네요.

특정 회수에서 느려지는 경우는 그 때, 그 세션이 다른 작업 - 일반적으로 세션프로세스에 wal 스위칭 작업을 해야 하는 경우인데, 그 새 트랜잭션 로그 파일을 새로 만들어야 하는 경우이거나, 체크포인트를 찍어야 하는 경우 - 때문에 느려집니다.

해결 방법은 일단 os 차원에서 디스크 i/o를 살펴보세요.

디스크 i/o와 그 느려지는 때가 같다면, 윗 경우가 거의 맞습니다.

이런 경우라면, 최대한 세션 스스로 체크포인트를 하지 않도록 checkpoing_segments 값을 크게 느리는 것 말고는 별로 없을 것 같네요.

또 다른 하나는 autovacuum 관련 작업이 해당 작업에 영향을 줄 가능성도 있는데,

이 부분은 autovacuum 로그를 남겨서 그 느려지는 시간대와 vacuum 수행 시간대가 일치하는지를 살펴보는 것이고요.

이렇게 애매한 경우는 직업 그 느려지는 시간대와, DB 상태를 파악해서 유추해 내는 방법 밖에 없습니다.

또 다른 하나는 OS 쪽에서 다른 작업을 주기적으로 진행해서 OS의 캐시가 DB 최적화 상태가 아니게 바뀌는 경우도 있겠지요.