계획은 내가 마르쿠스 Winand 웹 사이트에서 코드 예제를 재현하려고

Question

빠르게 실행 (Slow Indexes Part II)

테스트 케이스 :

1. 분석되지 않은 테이블을 만들고 인덱스를 소개합니다 전체 테이블 스캔보다 느리게 작동합니다.
2. 해당 색인이있는 검색어를 분석하십시오.
3. 색인 스캔을 끕니다.
4. 이 쿼리를 다시 분석하십시오.

이 테스트를 수행했으며 데이터베이스는 INDEX SCAN에서 SEQ SCAN으로 전환 중입니다.

그러나 실제 숫자를 살펴보면 SEQ SCAN 쿼리는 실제로 인덱스 INDEX 쿼리보다 느립니다.

planner가 비용이 많이 들고 느리더라도 SEQ SCAN 쿼리로 전환하는 이유는 무엇입니까? 여기

내 결과입니다 :

drop table if exists employees; 
CREATE TABLE employees (
    employee_id bigint   NOT NULL, 
    subsidiary_id bigint not null, 
    first_name text NOT NULL, 
    last_name  text NOT NULL, 
    date_of_birth DATE   NOT NULL, 
    phone_number text NOT NULL, 
    CONSTRAINT employees_pk PRIMARY KEY (subsidiary_id, employee_id) 
); 

SELECT setseed(0.5); 

insert into employees 
select a, 1, random()::text,random()::text, now(), '123123123' 
from generate_series(1,200000) as t(a) 
union all 
select a, 2, random()::text,random()::text, now(), '123123123' 
from generate_series(1,500000) as t(a); 

set enable_bitmapscan to false; 
explain analyze 
select * 
from employees 
where subsidiary_id = 1 and first_name = '0.550025727134198'; 

"QUERY PLAN" 
"Index Scan using employees_pk on employees (cost=0.42..8596.82 rows=12 width=116) (actual time=0.024..38.409 rows=1 loops=1)" 
" Index Cond: (subsidiary_id = 1)" 
" Filter: (first_name = '0.550025727134198'::text)" 
" Rows Removed by Filter: 199999" 
"Planning time: 0.114 ms" 
"Execution time: 38.429 ms" 

analyze employees; 

explain analyze 
select * 
from employees 
where subsidiary_id = 1 and first_name = '0.550025727134198'; 

"QUERY PLAN" 
"Seq Scan on employees (cost=0.00..19142.00 rows=1 width=66) (actual time=0.017..66.579 rows=1 loops=1)" 
" Filter: ((subsidiary_id = 1) AND (first_name = '0.550025727134198'::text))" 
" Rows Removed by Filter: 699999" 
"Planning time: 0.431 ms" 
"Execution time: 66.601 ms" 

set enable_seqscan to false; 

explain analyze 
select * 
from employees 
where subsidiary_id = 1 and first_name = '0.550025727134198'; 

"QUERY PLAN" 
"Index Scan using employees_pk on employees (cost=0.42..23697.20 rows=1 width=66) (actual time=0.041..36.159 rows=1 loops=1)" 
" Index Cond: (subsidiary_id = 1)" 
" Filter: (first_name = '0.550025727134198'::text)" 
" Rows Removed by Filter: 199999" 
"Planning time: 0.061 ms" 
"Execution time: 36.178 ms" 

Answer 1

플래너는 데이터 지역으로 계산하지 않습니다 - 그것은 디스크에서 읽는 모든 시간을 기대하고있다. 기본적으로 인덱스는 약간의 불이익을줍니다. 파일 시스템 캐시를위한 충분한 RAM이 있거나 IO가 활용되지 않으면 더 빠른 쿼리를 찾을 수 있습니다. 그러나 PostgreSQL planner는 활용 된 디스크 및 로우 캐시 용으로 구성되어 있으며 실제로 작동합니다. 아마도 당신은 부하없이 서버에서 테스트를했을 것입니다. 서버에서보다 현실적인로드를 시뮬레이트하고 테스트를 반복하십시오.