여러 열에 btree를 사용하는 postgresql 쿼리 최적화

-1

여러 개의 키에 btree 인덱스가있는 큰 테이블이 있습니다. 인덱스의 첫 번째 두 열을 수정하고 세 번째 열에 일방적 인 제한을 적용하여 쿼리를 만들면 일치하는 행 수가 매우 적더라도 매우 느린 쿼리가 발생합니다. 세 번째 열에 양방향 경계를 지정하면 쿼리가 대신 빠르게 수행됩니다. 아래의 코드 스 니펫을 참조하십시오.여러 열에 btree를 사용하는 postgresql 쿼리 최적화

postgresql이 인덱싱 된 열에 대한 하한을 빠르게 찾을 수 있어야하지만,이 경우에는 그렇지 않은 것으로 보입니다.

이 문제가 발생하는 이유에 대한 설명을 제공 할 수 있습니까? 그것을 고치는 방법? 쿼리 플래너를 실행하기로 결정하는 방법을 당신이 볼 수 있도록 각 쿼리의 시작 EXPLAIN를 추가

> select min(minute) from data_minutesample where probe_id = 19 and power = 0 and minute between 0 and 22780323; 
    min  
---------- 
22780262 
(1 row) 

Time: 28233.498 ms 

> select min(minute) from data_minutesample where probe_id = 19 and power = 0 and minute between 22780000 and 22780323; 
    min  
---------- 
22780262 
(1 row) 

Time: 13.946 ms 

> \d+ data_minutesample 
      Table "public.data_minutesample" 
[...] 
Indexes: 
    "data_minutesample_index_unique" UNIQUE, btree (probe_id, power, minute, proto_id, src_port, dst_port, src_addr, dst_addr)

출처

2013-05-26 Emanuele Paolini

테이블을 채우고 나서 'vacuum analyze'를 실행 했습니까? – wildplasser

PostgreSQL의 버전, 테이블 정의, 카디널리티, 타이밍 방법 (데이터 전송 포함 여부), explain.depesz.com에 이상적으로 게시 된 EXPLAIN ANALYZE의 출력은 질문없이해야합니다. –

보십시오.

제 생각에는 처음 값은 큰 범위의 값을 선택한다는 이유로 인덱스를 사용하지 않기로 결정하고 대신 테이블 스캔을 수행하는 것입니다. 아마도 그 범위에 실제로 하나의 일치하는 값만 있다는 것을 깨닫지 못할 것입니다.

플래너에 최신 통계가 있는지 확인하기 위해 테이블에 ANALYZE을 실행하면 더 나은 결정을 내리는 데 도움이됩니다.

출처

2013-05-26 17:44:22 TomH

여러 열에 btree를 사용하는 postgresql 쿼리 최적화

답변

관련 문제