이 PostgreSQL 쿼리가 인덱스를 사용해야합니까?

Question

나는 두 개의 테이블이 있습니다

CREATE TABLE soils (
    sample_id  TEXT PRIMARY KEY, 
    project_id  TEXT, 
    technician_id TEXT 
); 
CREATE INDEX soils_idx 
ON soils 
USING btree 
(sample_id COLLATE pg_catalog."default"); 

CREATE TABLE assays (
    sample_id TEXT PRIMARY KEY, 
    mo_ppm  NUMERIC 
    ); 
CREATE INDEX assays_idx 
ON assays 
USING btree 
(sample_id COLLATE pg_catalog."default"); 

각 테이블 유형의 TEXT의 약 20 추가 열 각각합니다 (DDL 생략 여기에 시간을 절약하기 위해 위의 게시), 현실에서, 50 만 개 레코드에 대한 포함합니다. 내가 쿼리 수행 할 때

는 :

EXPLAIN SELECT 
    s.sample_id, s.project_id, s.technician_id, a.mo_ppm 
FROM 
    soils AS s INNER JOIN assays AS a ON s.sample_id = a.sample_id 

을 나는 2 SEQ 스캔보다는 인덱스에 대한 조회를 얻을. 그것은 예상 된 행동인가?

Answer 1

WHERE 조건이 없으므로 전체 표를 효과적으로 읽습니다. 순차적 스캔을 실행하고 인덱스 조회를 건너 뛰는 것이 더 저렴할 수 있습니다.

보십시오

EXPLAIN SELECT 
    s.sample_id, s.project_id, s.technician_id, a.mo_ppm 
FROM 
    soils As s INNER JOIN assays As a ON s.sample_id = a.sample_id 
WHERE <some condition that returns a few rows>; 

.. 적어도 하나의 인덱스 (WHERE 조건)에 따라 사용한다.

PRIMARY KEY 열에 인덱스를 정의 할 필요가 없습니다. PK 제약 조건은 고유 인덱스를 자동으로 생성하여 구현됩니다. 추가 색인은 중복되어 사용하지 않습니다.

외래 키 열에 대한 색인은 좋은 생각 일 수 있지만 귀하의 예에서는 이상하게 보입니다. 두 테이블처럼 하나의 테이블로 결합 될 수 있습니다. 아마도 테스트 케이스에 대해 단순화 된 것일뿐입니다.

마지막으로 큰 테이블의 경우 text (serial) 열 대신 간단한 integer 기본 키를 사용하는 것이 좋습니다. 일반적으로 여러 가지 이유로 더 빠릅니다.

Answer 2

예, 정상적인 동작입니다. 반면에 귀하의 random_page_cost, seq_page_cost 및 effective_cache_size 설정에 따라 다릅니다. 쿼리에 WHERE 절이 없으므로 모든 항목을 순차적으로 읽는 것이 더 빠릅니다.

set enable_seqscan = off; 
explain analyse <your query>; 

를 다음 계획/비용/IO 대기를 비교합니다 (서열-검색 기능을 중지 할 수는 아니지만 매우 높은 비용을 얻는다 - ~ 1E7 (또는 1E8)) : 당신은 순차 검색 불이익을 시도 할 수 있습니다.

쿼리에 SSD와 WHERE 절이있는 경우 random_page_cost to 1.5..2.5을 낮추고 PG에서 index를 사용하도록 권장 할 수 있습니다.