분할 된 테이블의 인덱싱 된 열로 필터링하는 쿼리를 실행하면 전체 테이블을 검색하는 경우가 있습니다.postgresql 8.3.7의 분할 된 테이블에서 인덱스를 사용하는 방법
분명히, 이것은 PostgreSQL의에서 알려진 문제이며, 그것은 세부 here 설명입니다.
각 파티션에서 쿼리를 수행하고 모든 결과에 UNION을 수행하는 것보다이 다른 주위에 더 우아한 방법이 있나요?
인덱스는 PostgreSQL의 관련 파티션 만 스캔 할 수 있습니다. 하지만 제대로 작동하려면 모든 것을 올바르게 설정해야하며, 문서화 된 긴 목록의 단계를 놓치기가 쉽습니다. http://www.postgresql.org/docs/current/static/ddl-partitioning.html
실현해야 할 주요 사항은 순차적 검색을 피하기 위해 PostgreSQL에 충분한 정보를 제공해야하므로 일부 파티션에서 찾고자하는 데이터를 가질 수 없다는 것을 증명할 수 있습니다. 조회 결과의 잠재적 소스로 생략됩니다. 링크 기사에서 seq 스캔 문제에 대한 해결책으로 이것을 지적합니다. "각 파티션의 날짜 필드에 범위 제한을 추가하면이 쿼리는"최신 "파티션을 먼저 쿼리하고 작업을 수행하는 루프로 최적화 할 수 있습니다 다른 모든 파티션의 범위보다 높은 단일 값을 찾을 때까지 뒤로 이동하십시오. "-하지만 변경 후에 볼 수있는 개선 된 계획은 표시하지 않습니다.
일반적인 실수 당신이 만든 수 있습니다
postgresql.conf 파일에서 년 - constraint_exclusion 매개 변수는 기본적으로 꺼져 있습니다. 이 기본값을 사용하면 기대 한 바를 얻을 수 없습니다.
은 그들 각각의 내부에 무엇을 알고에서 플래너를 유지 CHECK를 사용하여 파티션을 비 중첩 만들 -Didn't. 이 단계를 놓치지 만 올바른 파티션으로 데이터를 가져올 수는 있지만 플래너는이를 알 수 없습니다.
- 각 파티션에 색인을 지정하지 않았으며 마스터 테이블에서만 색인을 작성했습니다. 이렇게하면 관련 파티션에서 순차적으로 스캔 할 수 있기 때문에 위와 같이 나쁘지는 않지만 좋지 않습니다.
가 곧 PostgreSQL의 릴리스에 모두 쉽게이를 만들기 위해 몇 가지 작업있다 (constraint_partition을 설정하면 8.4에서 상당히 자동이며, 파티션 설정 자동화 일종의에서 근무하고 있습니다). 지금 당장 지침을주의 깊게 따르고 이러한 모든 문제를 피한다면 작동 할 것입니다.
또한 Postgres 성능 메일 링리스트의 http://archives.postgresql.org/pgsql-performance/에서 문의하십시오. –
작성자가 파티셔닝에 지나치게 익숙하지 않기 때문에 연결된 기사가 정확하지 않습니다. 그는 각 파티션에 대해 constraint_exclusion 또는 인덱스를 활성화하지 않았습니다. –
쿼리가 파티션 경계를 넘기 때문에 색인을 제외해야하는 이유를 이해할 수 없습니다. 필자의 경우, 각 파티션에 인덱스가있는 컬럼에 대해 매우 작은 값 세트를 찾으려고 할 때이 문제점을 발견했습니다. 파티션의 고유 C 럼을 선택하면 인덱스 스 5이 g 용됩니다. 부모 테이블에서 같은 일이 각 파티션의 전체 테이블 스캔을 수행 한 다음 병합 한 다음 정렬합니다. "select union select union select ..."에서 distinct column을 선택하는 것이 "parent에서 distinct column을 선택"하는 것보다 빠릅니다. planner가 명백한 이유를 알지 못하는 사람은 누구입니까? – ideasculptor