CLUSTER 후에 REINDEX가 필요합니까?

12

인덱스로 테이블을 재정렬하기 위해 CLUSTER를 사용하는 것을 고려하고 있습니다. 이러한 테이블 데이터의 재생산으로 인해 기존의 모든 인덱스가 부풀어 오르거나 쓸모가 없게됩니다. CLUSTER 후에 REINDEX가 필요하다는 표시가 있습니다. CLUSTER 가 REINDEX를 수행 한다는 것을 나타내는 다른 참조를 찾았습니다 . 공식 문서는 REINDEX 클러스터의 일부가되는 또는 (가 CLUSTER 후 ANALYZE 실행 제안 않지만) 요구에 대해 전혀 아무것도 말하지 않는다

CLUSTER 이후에 REINDEX가 필요한지 여부를 확실하게 (즉, 공식 문서에 대한 일종의 참조로) 말할 수 있습니까?

postgresql

— 나무
소스

2

나는 그것이 필요하다고 생각하지 않습니다. cluster행을 재배치하므로 어쨌든 색인 정보를 업데이트해야합니다.

— a_horse_with_no_name

예, 그러나 내가 찾은 토론의 절반에있는 이론은 지수가 팽창한다는 것입니다.

— TREE

12

CLUSTER효과적으로 재 인덱싱 할 필요가 없습니다 .

보다 구체적으로, CLUSTER소스 테이블을 잠근 다음 대상 인덱스에 따라 순서가 지정된 새 사본 을 작성합니다 . 새 복사본에 인덱스를 만든 다음 이전 테이블과 인덱스를 새 테이블로 바꿉니다.

VACUUM FULL9.0+ 에서도 마찬가지입니다 .

당신이 CLUSTER팽창 지수를 제안하는 토론을보고 있다면 CLUSTER9.0 이전과 같이 작동 한다고 가정하는 사람들 일 수 있습니다 VACUUM FULL. 또한 이전 VACUUM FULL구현으로 인한 인덱스 팽창을 언급 CLUSTER하고 대안으로 제안 하는 토론을보고 잘못 읽을 수도 있습니다 .

이것은 설명서에 암시되어 있습니다 .

인덱스 순서로 테이블 데이터를 포함하는 테이블의 임시 사본이 작성됩니다. 테이블에있는 각 인덱스의 임시 복사본도 만들어집니다 . 따라서 최소한 테이블 크기와 인덱스 크기의 합과 같은 여유 공간이 디스크에 있어야합니다.

말하지는 않지만 임시 사본 은 원래 테이블을 대체한다는 것 입니다. (굵은 광산).

— 크레이그 링거
소스

1

CLUSTER가 인덱스를 대체한다는 참조가 있습니까?

— TREE

1

@TREE가 추가되었습니다. 문서는 임시 테이블과 색인이 원본을 대체한다고 명시 적으로 알려주지 않지만 CLUSTER 전후에 실제로 데이터 디렉토리를 보거나 소스 코드를 검사하는 경우에 해당됩니다.

— Craig Ringer

이것을 테스트했으며 적어도 테스트 시나리오에서는 인덱스 파일 크기가 줄었습니다. 그러나 이것은 하나의 시나리오 일 뿐이며 동작에 영향을 미치는 많은 변수 (인덱스 수, 디스크의 총 크기 등)가있을 수 있으므로 간단한 테스트를 신뢰할 수 없습니다.

— TREE

1

@TREE 가능한 모든 상황에서 동작을 이해하는 데 절대적인 확신을 얻으려면 소스 코드를 읽어야합니다. 내가 말할 수있는 CLUSTER것은 색인을 다시 쓰지 않는 상황을 알지 못한다는 것 입니다. 실제 파일을 검사 base/하면 분명히 새로운 것이 나타납니다 relfilenode. 아직 가지고 있지 않은 문제에 대해 걱정하고있는 것 같습니다.

— Craig Ringer

8

나는 이것에 a_horse_with_no_name을 사용하고 있습니다 : 당신은 인덱스를 다시 만들 필요가 없습니다. CLUSTER문서에 언급되지 않은 것 외에도 REINDEX페이지를 추가로 참조 할 수 있습니다.

REINDEX를 사용하는 몇 가지 시나리오가 있습니다.

색인이 손상되었으며 더 이상 유효한 데이터가 없습니다. 이론 상으로는 이런 일이 발생하지 않아야하지만 실제로 소프트웨어 버그 나 하드웨어 오류로 인해 색인이 손상 될 수 있습니다. REINDEX는 복구 방법을 제공합니다.

인덱스가 "부풀어"져서 비어 있거나 거의 비어있는 페이지가 많이 있습니다. 이는 특정 드문 액세스 패턴으로 PostgreSQL의 B- 트리 인덱스에서 발생할 수 있습니다. REINDEX는 데드 페이지없이 새 버전의 인덱스를 작성하여 인덱스의 공간 소비를 줄이는 방법을 제공합니다. 자세한 정보는 23.2 절을 참조하십시오.

색인에 대한 스토리지 매개 변수 (예 : fillfactor)를 변경했으며 변경 사항이 완전히 적용되도록하려고합니다.

CONCURRENTLY 옵션을 사용한 인덱스 빌드가 실패하여 "유효하지 않은"인덱스가 남습니다. 이러한 인덱스는 쓸모가 없지만 REINDEX를 사용하여 다시 작성하는 것이 편리 할 수 있습니다. REINDEX는 동시 빌드를 수행하지 않습니다. 프로덕션을 방해하지 않고 인덱스를 작성하려면 인덱스를 삭제하고 CREATE INDEX CONCURRENTLY 명령을 다시 발행해야합니다.

분명히, CLUSTER어떤 경우에도 해당되지 않습니다.

그리고 CLUSTER문서 에는 작은 문장이 있습니다 .

[클러스터링 중] 테이블에서 각 인덱스의 임시 사본도 작성됩니다.

이는 테이블 자체와 마찬가지로 프로세스 중에 인덱스가 다시 정렬되므로 인덱스를 다시 색인화 할 수 없게됩니다.

— 데소
소스

그 제안은 확실히 존재하며, 테스트는 그것을 확인하는 것으로 보입니다. 문서에서 실제로 색인이 (영구적으로) 다시 작성 되었다고 말한 경우이 동작에 더 의존하는 것이 좋습니다 .

— TREE

2

여기에 문서 패치에 대한 내용이 있습니다. 인덱스를 다시 만드는 방법에 대한 설명서가 더 명확해야합니다.

— Erwin Brandstetter

이 시점에서 필자의 의심은 개발자 가이 구현에 영구적으로 묶여 있기를 원하지 않기 때문에 공식적 으로이 동작을 문서화하고 싶지 않다는 것입니다.

— TREE

@TREE 버전마다 많은 기능 변경이 있으며 문서는 그에 따라 (대부분) 변경됩니다. 아마도 사양도 변경됩니다 :), 나는 아무데도 넥타이가 보이지 않습니다.

— dezso

@dezso 사실이지만 문서화 된 기능을 제거하는 것을 꺼려합니다. 일반적으로 문서의 품질을 고려할 때, 나는 여전히이 동작의 생략이 의도적이라고 가정합니다.

— TREE

5

디스크 공간 복구 섹션 에서 참조를 찾았습니다 .

이러한 테이블이 있고 사용중인 디스크 공간을 재 확보해야하는 경우 VACUUM FULL 또는 CLUSTER 또는 ALTER TABLE의 테이블 재 작성 변형 중 하나 를 사용해야 합니다. 이 명령은 테이블의 전체 새 사본을 다시 작성하고 새 인덱스 를 빌드 합니다.

— 나무
소스

-3

내 의견으로는 모든 대답을 분석하는 것이 올바른 방법은 클러스터 전에 색인을 다시 작성하는 것입니다. 설명서에서 클러스터가 다시 색인을 생성하는지 여부와 순서의 여부에 관계없이 색인 사본 만 알지 못하기 때문에 색인 된 색인으로 인해 클러스터 된 테이블이 더 좋아질 것이라고 생각합니다. 그 후 분석은 작업을 완료합니다. 군집 및 / 또는 재 색인이 죽은 튜플을 해제하지 않는 한 모든 진공 상태가 완전히 소진되지 않는 것처럼 보입니다.

— 아이슬란 루이스 웬들 링
소스

내가 허용 대답에 언급 된 바와 같이, 문서는 않습니다 그 인덱스는 그냥 클러스터 명령에 대한 페이지에 재건 될 것이라고 말했다.

— TREE

그리고 모두 CLUSTER와 VACUUM FULL새로운 물리적 테이블을 생성 - 단순히 후 죽은이있을 수 없습니다. 이전 사본에 사용 된 공간은 작업이 끝나면 해제됩니다.

— dezso

과연. 테이블과 모든 인덱스를 다시 작성합니다. 그러나 클러스터가 테이블을 다시 정렬하는 데 사용하는 인덱스에 대해서는 의문의 여지가 있습니다. 먼저 다시 인덱싱되거나 테이블을 그대로 재정렬하는 데 사용됩니까? 그리고 그 색인이 다시 만들어 집니까? 문제가있는 색인으로 인해 몇 가지 문제가 발생할 수 있습니다.

— Aislan Luiz Wendling