2013-06-14 2 views
0

나는 다음과 같은 PostgreSQL의 테이블이 : 나는 다음과 같은 명령으로이 테이블을 갱신PostgreSQL을 업데이트 명령이 너무 느립니다

CREATE TABLE "initialTable" (
    "paramIDFKey" integer, 
    "featAIDFKey" integer, 
    "featBIDFKey" integer, 
    "featAPresent" boolean, 
    "featBPresent" boolean, 
    "dataID" text 
); 

을 : 당신이, 내가 각각에 대한 dataID를 업데이트하고 볼 수 있듯이

UPDATE "initalTable" 
SET "dataID" = "dataID" || '#' || 'NEWDATA' 
where 
    "paramIDFKey" = parameterID 
    and "featAIDFKey" = featAIDFKey 
    and "featBIDFKey" = featBIDFKey 
    and "featAPresent" = featAPresent 
    and "featBPresent" = featBPresent 

열. 이 업데이트는 추가로 작동합니다. 이전 데이터에 새 데이터를 추가합니다.

너무 느립니다. 특히 "dataID"열이 커지면.

다음이다 "설명"결과 :

"Bitmap Heap Scan on "Inexact2Comb" (cost=4.27..8.29 rows=1 width=974) (actual time=0.621..0.675 rows=1 loops=1)" 
" Recheck Cond: (("paramIDFKey" = 53) AND ("featAIDFKey" = 0) AND ("featBIDFKey" = 95))" 
" Filter: ("featAPresent" AND (NOT "featBPresent"))" 
" -> Bitmap Index Scan on "InexactIndex" (cost=0.00..4.27 rows=1 width=0) (actual time=0.026..0.026 rows=1 loops=1)" 
"  Index Cond: (("paramIDFKey" = 53) AND ("featAIDFKey" = 0) AND ("featBIDFKey" = 95) AND ("featAPresent" = true) AND ("featBPresent" = false))" 
"Total runtime: 13.780 ms" 

및 버전 : 어떤 제안이

"PostgreSQL 8.4.14, compiled by Visual C++ build 1400, 32-bit" 

거기를

"Bitmap Heap Scan on "initialTable" (cost=4.27..8.29 rows=1 width=974)" 
" Recheck Cond: (("paramIDFKey" = 53) AND ("featAIDFKey" = 0) AND ("featBIDFKey" = 95))" 
" Filter: ("featAPresent" AND (NOT "featBPresent"))" 
" -> Bitmap Index Scan on "InexactIndex" (cost=0.00..4.27 rows=1 width=0)" 
"  Index Cond: (("paramIDFKey" = 53) AND ("featAIDFKey" = 0) AND ("featBIDFKey" = 95) AND ("featAPresent" = true) AND ("featBPresent" = false))" 

분석 설명?

+2

http://stackoverflow.com/tags/postgresql-performance/info ... 및 전체 *'update' 문에 따라 'explain analyze'등을 추가하십시오. –

+0

설명을 추가했습니다. – Bipario

+0

'explain ANALYZE'를 추가하십시오. planner가 기대하는 것 이외에 실제 일어나고있는 것을 볼 수 있습니다. Craig가 인용 한 페이지에서 요청 된 나머지 정보도 도움이됩니다. – kgrittn

답변

0

첫째, 나는 이것이 실제로 문제가 될 것이라고 확신하지 않습니다. 단일 쿼리에 대해 15ms가 너무 길면 조기에 최적화하고 병목 현상이 실제로 있는지 질문하고 시작해야합니다. 그렇다면 데이터베이스를 어떻게 사용하고 있는지 다시 생각해보십시오. 쿼리는 explain suggsts보다 더 빨리 실행될 수 있습니다 (일부 쿼리는 EXPLAIN ANALYZE 하에서 4 배 느리게 실행되는 것을 보았습니다). 먼저 애플리케이션을 프로파일 링하고 실제 병목 현상을 찾으십시오.

이것이 병목 현상이라고 생각하면 인덱싱 대상을 자세히 살펴볼 수 있습니다. 인덱스가 너무 많으면 쓰기 작업이 느려지고 업데이트 쿼리와 관련이 있습니다. 이는 업데이트의 모든 열과 함께 새 인덱스를 추가하고 필요에 따라 다른 인덱스를 제거하는 것을 의미 할 수 있습니다. 그러나, 나는 정말로 당신이 그 쿼리에서 더 많은 것을 얻으 려하지는 않습니다.