더 빠른 SELECT COUNT (*) FROM 테이블을 위해 인덱스 구성 테이블을 포장 할 수 있습니까?

Question

COUNT (*) FROM 테이블을 수행하지 않고 테이블의 현재 전체 행을 얻는 방아쇠를 만드는 것이 번거로울 수 있습니다. Postgres 8.5의 계획된 인덱스 구성 테이블이 가능하게 할 수 있다면 생각하고 있습니까?

Answer 1

인덱스 구성 테이블이 모든 보이는 튜플을 계산하기 위해 스캔하는 것이 더 빠를 것이라고는 생각하지 못했습니다. 논리적으로 볼 때 데이터가 b-tree 리프 노드 또는 기존 힙 형식으로 구성되어 있는지 여부와 관계없이 동일한 양의 데이터를 처리해야합니다.

현재 postgresql 인덱스는 [key, ctid] 쌍 (본질적) 만 저장합니다. (ctid는 본질적으로 "rowid"- 힙 페이지 번호와 튜플 라인 포인터 인덱스입니다.) 따라서 각 튜플에 대해 [xmin, xmax]를 확인해야하기 때문에 인덱스를 통해 테이블의 행을 계산할 수는 없습니다 그리고 그것은 힙에있는 데이터로만 유지됩니다.

인덱스에 [xmin, xmax]를 넣어도됩니다. 수시로 제안 사항을 제안 할 수 있습니다. 그러나 인덱스를 확장하고 유용하게 사용하려면 모든 업데이트/삭제가 최신 상태로 유지되어야합니다. 업데이트를 수행하는 작업이 이제는 몇 배로 확장 되었기 때문에 문제가 발생합니다. 테이블의 인덱스 수만큼. tsvector와 같은 무거운 색인의 경우 또는 값 비싼 사용자 표현에 기반한 색인의 경우에는 다소 시간이 걸릴 수 있습니다. 일부 불쾌한 경우에는 색인에 실제로 게재되는 행이 표시되지만 전혀 표시되지 않습니다. 더미. 그리고이 연습의 전체적인 요점은 가능한 경우 데이터베이스가 인덱스의 실시간 정보에 독점적으로 의존 할 수 있어야한다는 것입니다. 8.3 (힙만있는 튜플)에서 속도를 높이기 위해 노력한 무 인덱스 열을 업데이트하더라도이 비용이 발생합니다.

인덱스를 [xmin, xmax]가있는 것으로 표시하는 것이 하나의 가능성이라고 가정합니다. 그렇게 pkey 인덱스 만 표시하십시오. 이것이 언제 이점 이었는지를 알아내는 데있어 플래너가 변경되어야합니다. 이것은 꽤 많은 일처럼 보입니다.

오라클 (그리고 클러스터 된 인덱스가있는 테이블이 기본적으로 인덱스 구성되어있는 SQL Server)에서 수행하는 인덱스 구성 테이블은 [key, tuple]을 기본 키 인덱스에 저장하여 작동합니다 대신에 (그리고 다른 모든 것들에서 아마도 [key, pkey]) ctid도 heap도 없다. 그래서 "튜플"은 [xmin, xmax, cminmax, natts, ....] 등을 포함 할 것이고 단지 인덱스를 스캔함으로써 "select count (*) from table"을 만족시킬 수 있습니다. 그러나 이것은 기본적으로 힙에서 튜플을 검색하는 것과 동일합니다. 이제는 "인덱스"에 있기 때문에 마술처럼 적은 공간을 차지하지 않습니다.

AFAICT 인덱스 구성 테이블의 주된 이유는 단일 기본 키 인덱스가있는 작은 테이블이 3 대신 1 페이지를 차지하고 기본 키로 인덱스 스캔이 약간 빠르다는 것입니다. 오라클과 관련된 IOT에 대한 조언은 오라클이 정적 차원 테이블을 대상으로 한 것이지 일반 용도가 아닌 것이 었으며 부분적으로는 보조 인덱스를 유지 관리하는 데 드는 비용 때문이었습니다 (오라클 스토어는 [ 키, pkey] IOT 보조 인덱스, 대신 오히려 일종의 대체 rowid).

Answer 2

이 방법은 날짜가 있지만 PostgreSQL 9.2에서는 개수 만 (*)을 수행 할 수있는 인덱스 전용 검색을 사용합니다. 당신이 링크를 제공 할 수 -

는

• Is "count(*)" much faster now?