2009-12-22 3 views
1

PostgreSQL에 메모리에 읽을 테이블이 있습니다. 3 열 200 행의 매우 작은 테이블이며, 나는 단지 select col1, col2, col3 from my_table을 수행합니다.작은 테이블에서 PostgreSQL 순차 검색 느림

개발 컴퓨터에서이 컴퓨터가 Mac OS FileVault의 VirtualBox 인 경우에도 매우 빠릅니다 (1ms 미만).

그러나 프로덕션 서버에서는 일관되게 600 밀리 초가 걸립니다. 프로덕션 서버의 사양이 낮을 수 있으며 데이터베이스 버전도 이전 버전 (7.3.x)이지만 큰 차이점 만 설명 할 수는 없습니다.

두 경우 모두 explain analyze을 db 서버 자체에서 실행 중이므로 네트워크 오버 헤드가 될 수 없습니다. 쿼리 실행 계획은 두 경우 모두 간단한 순차 전체 테이블 검색입니다. 그 당시에는 생산 기계에서 계속 진행되고 있던 일이 없었기 때문에 논쟁도있었습니다.

왜 이렇게 느린 지 알 수 있습니까? 어떻게해야합니까?

+0

업그레이드 ASAP - 7.3은 공식적으로 지원되지 않습니다. –

답변

3

아마도이 데이터베이스를 올바르게 VACUUMing하지 않은 것 같습니다. 7.3은 입니다. 너무 오래되어 AutoVacuum이 없으므로 수동으로 수행해야합니다 (cron 작업 권장). 이 테이블에 많은 업데이트 (시간 경과에 따라)가 있고 VACUUM을 실행하지 않으면 액세스가 매우 느립니다.

+0

언제 VACUUM이 마지막으로 완료되었는지 알 수 있습니까? – Thilo

+0

@Thilo : on 7.3 - 당신은 거의 알 수 없습니다. –

+2

정말 좋은 방법은 없지만 디스크에있는 테이블 파일의 크기 (pg_class의 relfilenode를 확인하여 파일 이름을 찾으십시오)를 테이블에 있어야한다고 생각하는 데이터의 양과 비교할 수 있습니다. 그렇게하면 테이블에 VACUUM FULL 및 REINDEX를 실행해야합니다. 아, 그리고 다른 많은 사람들처럼 Postgres의 지원 버전으로 업그레이드하십시오. –

0

여러 번 쿼리를 실행하면 어떻게됩니까? fisrt 실행은 느려야하지만 첫 번째 실행이 캐시에 데이터를 저장하기 때문에 다른 캐시가 더 빨라야합니다.

BTW : 아무런 제한없이 SELECT ... FROM을 수행하면 seq 스캔이 100 % 정상이고 값을 검색하기 위해 seq 스캔을해야하며 제한이 있으므로 아무 것도 없습니다 인덱스 스캔을 수행해야합니다.

주저하지 말고 Explain Analyze 쿼리 결과를 게시하십시오.

PostgreSQL 7.3은 정말로 오래되었지만 최신 버전으로 업그레이드 할 수 있습니까?

+0

두 번째로 빠르게 돌아 가지 않습니다. 나는 전체 테이블을 읽기위한 이상적인 액세스 경로가 될 것이므로 순차 스캔에 아무런 문제가 없다. 그 스캔이 더 짧은 시간에 끝나길 바랄뿐입니다 ... – Thilo

2

분명히 팽창했습니다. 해당 테이블의 진공 분석을 실행하십시오. 또한 - 업그레이드. 7.3은 더 이상 지원되지 않습니다.

+0

VACUUM이 spot-on 인 것으로 보입니다. 나는 작전 녀석들에게 그렇게하도록 요청해야한다. 테이블이 엄청나게 줄어들 것이라는 것을 확인하기 위해, 지금 얼마나 많은 블록을 차지하는 지 어떻게 볼 수 있습니까? 그런 다음 개발 컴퓨터에서 가지고있는 것과 비교할 수 있습니다. – Thilo

+0

* 축소되지 않습니다. 그것은 다소 줄어들지 만, 나는 그것에 정말로 의지하지 않을 것입니다. –

+0

VACUUM은 무엇을 축소하지 않을까요? – Thilo

관련 문제