2011-03-18 2 views
0

별색 선택, 비트 맵 힙 스캔 제거

create table a (x int, y int); 
create index a_x_y on a(x, y); 

select distinct x from a where y = 1과 같은 쿼리는 인덱스 만 사용하고 대신 인덱스를 사용하여 y로 필터링 한 다음 비트 맵 힙 스캔을 수행하여 x의 모든 값을 얻습니다.

--------------------------------------------------------------------------------------------------------------------- 
HashAggregate (cost=15.03..15.05 rows=2 width=4) (actual time=0.131..0.131 rows=0 loops=1) 
    -> Bitmap Heap Scan on a (cost=4.34..15.01 rows=11 width=4) (actual time=0.129..0.129 rows=0 loops=1) 
     Recheck Cond: (y = 1) 
     -> Bitmap Index Scan on a_x_y (cost=0.00..4.33 rows=11 width=0) (actual time=0.125..0.125 rows=0 loops=1) 
       Index Cond: (y = 1) 

이 유형의 쿼리에는 어떤 종류의 인덱스가 필요합니까?

+0

빈 계획이 아니라 실제 계획을 게시하십시오. 최소한 행의 수, 반환되는 행의 수 및 소요 시간을 알아야합니다. – Tometzky

답변

1

비트 맵 힙 스캔은 0.129 밀리 초가 걸리지 만 빠르지 않습니까?

"인덱스 만 검사"하는 경우 PostgreSQL에서 아직 수행 할 수 없습니다.

+0

예제로 사용한 빈 테이블은 빠릅니다. :) – ibz

+0

예, 색인 스캔 만하고 싶습니다. 기본적으로 모든 고유 한 값이 필요합니다. 인덱스는이를 가져 오기에 충분해야합니다. – ibz

+0

내가 말했듯이, 이것은 PostgreSQL에서는 불가능합니다. –

3

인덱스의 두 번째 열을 필터링하므로 직접 인덱스 스캔에 사용되지 않습니다. 인덱스를 x, y 대신 x, y로 변경하면 찾고있는 스캔을 제공 할 수 있습니다.

또한 실제 데이터를 테이블에 넣으면 다른 쿼리 계획을 얻을 수 있으므로 실제 데이터로 테스트해야합니다.

마지막으로 비트 맵 검사 노드를 오해하고 있다고 생각합니다. 비트 맵 힙 스캔은 실제 힙 스캔을 수행하는 것을 의미하지 않습니다. 인덱스를 사용하여 관심있는 행이있는 페이지를 찾은 다음 두 번째 작업의 테이블에서만 해당 페이지를 스캔합니다.

+0

1) 나는 x, y, y, x 두 가지 방법을 시도했다. 2) 많은 데이터를 가지고 실제 테이블을 테스트했습니다. 이 비어있는 예제 테이블은 동일한 쿼리 계획을 가지고 있었기 때문에 이것을 간략하게 게시했습니다. 혼란을 드려 죄송합니다. 3) 여전히 쿼리가 매우 느립니다 (그리고 여러 번 실행해야합니다). 나는 어떻게 든이 색인을 사용하기를 바라고 있습니다. – ibz

+1

y, x는 적어도 이론적으로는 사용할 수 있어야하므로, 어떤 이유로 든 너무 비싸다고 생각할 가능성이 큽니다. ase가 업그레이드해야하는 PostgreSQL의 정말로 오래된 버전을 사용하고 있지 않다면 :-) 크로스 컬럼 상관 관계에는 여전히 몇 가지 문제가 있지만 더 자세한 내용 없이는 논평하기가 어렵습니다. 상황을 pgsql- 성능 메일 링리스트에 게시하고 싶을 수도 있습니다. 그러나이 경우 실제 * 쿼리/db 조합의 EXPLAIN ANALYZE 출력을 포함 시키십시오. –