PostgreSQL's진공명령은 여러 가지 이유로 정기적으로 각 와이즈 토토을 처리해야 합니다.

이러한 각 이유는 수행을 결정합니다.진공다음 하위 섹션에 설명된 대로 다양한 빈도와 범위의 작업.

다음에는 두 가지 변형이 있습니다.진공: 표준진공그리고진공 가득 참. 진공 가득 참더 많은 디스크 공간을 확보할 수 있지만 훨씬 더 느리게 실행됩니다. 또한,의 표준형진공프로덕션 데이터베이스 작업과 동시에 실행될 수 있습니다. (다음과 같은 명령)선택, 삽입, 업데이트및삭제다음과 같은 명령으로 테이블 정의를 수정할 수는 없지만 계속해서 정상적으로 작동합니다.와이즈 토토 변경청소되는 동안.)진공이 가득 참필요합니다접속 독점작업 중인 와이즈 토토을 잠그므로 와이즈 토토의 다른 사용과 동시에 수행할 수 없습니다. 따라서 일반적으로 관리자는 표준을 사용하도록 노력해야 합니다.진공그리고 피하세요진공 가득 참.

진공상당한 양의 I/O 트래픽을 생성하여 다른 활성 세션의 성능을 저하시킬 수 있습니다. 백그라운드 진공 청소가 성능에 미치는 영향을 줄이기 위해 조정할 수 있는 구성 매개변수가 있습니다. 참조섹션 19.4.4.

에PostgreSQL,업데이트또는삭제15427_15580MVCC, 참조13장): 행 버전은 잠재적으로 다른 트랜잭션에 표시되는 동안 삭제하면 안 됩니다. 그러나 결국 오래되었거나 삭제된 행 버전은 더 이상 어떤 트랜잭션에도 관심이 없습니다. 그런 다음 디스크 공간 요구 사항이 무제한으로 증가하는 것을 방지하기 위해 차지하는 공간을 새 행에서 재사용할 수 있도록 회수해야 합니다. 이는 다음을 실행하여 수행됩니다.진공.

의 표준 형식진공와이즈 토토과 인덱스에서 데드 행 버전을 제거하고 나중에 재사용할 수 있는 공간을 표시합니다. 그러나 와이즈 토토 끝에 있는 하나 이상의 페이지가 완전히 비어 있고 배타적 와이즈 토토 잠금을 쉽게 얻을 수 있는 특수한 경우를 제외하고는 운영 체제에 공간을 반환하지 않습니다. 대조적으로,진공 가득 참불용 공간 없이 완전히 새로운 버전의 테이블 파일을 작성하여 테이블을 적극적으로 압축합니다. 이렇게 하면 테이블 크기가 최소화되지만 시간이 오래 걸릴 수 있습니다. 또한 작업이 완료될 때까지 테이블의 새 복사본을 위한 추가 디스크 공간이 필요합니다.

일상적인 진공 청소의 일반적인 목표는 표준을 수행하는 것입니다.진공필요를 피할 수 있을 만큼 자주진공이 가득 참. autovacuum 데몬은 이런 방식으로 작동하려고 시도하지만 실제로는 실행되지 않습니다.진공 가득 참. 이 접근 방식에서 아이디어는 테이블을 최소 크기로 유지하는 것이 아니라 디스크 공간의 안정적인 상태 사용을 유지하는 것입니다. 각 테이블은 최소 크기에 해당하는 공간에 더해 진공 실행 사이에 사용되는 공간을 차지합니다. 하지만진공 가득 참와이즈 토토을 최소 크기로 다시 축소하고 디스크 공간을 운영 체제에 반환하는 데 사용할 수 있습니다. 와이즈 토토이 나중에 다시 커지면 별 의미가 없습니다. 따라서 중간 빈도 표준진공실행은 드물게 실행하는 것보다 더 나은 접근 방식입니다.진공 가득 참대량 업데이트된 테이블을 유지하기 위해 실행됩니다.

일부 관리자는 부하가 적은 밤에 모든 작업을 수행하는 등 스스로 진공 청소 일정을 잡는 것을 선호합니다. 고정된 일정에 따라 진공 청소를 수행할 때 어려운 점은 테이블의 업데이트 활동이 예기치 않게 급증하는 경우 테이블이 너무 커져서 다음과 같은 수준이 될 수 있다는 것입니다.진공 가득 참공간을 확보하려면 정말 필요합니다. autovacuum 데몬을 사용하면 데몬이 업데이트 활동에 대한 응답으로 동적으로 진공 청소를 예약하므로 이 문제가 완화됩니다. 작업 부하가 극도로 예측 가능한 경우가 아니면 데몬을 완전히 비활성화하는 것은 현명하지 않습니다. 한 가지 가능한 절충안은 비정상적으로 과도한 업데이트 활동에만 반응하도록 데몬의 매개변수를 설정하여 예정된 동안 일이 통제 불능 상태가 되는 것을 방지하는 것입니다.진공s는 부하가 일반적일 때 대부분의 작업을 수행할 것으로 예상됩니다.

autovacuum을 사용하지 않는 경우 일반적인 접근 방식은 데이터베이스 전체에 걸쳐 예약하는 것입니다.진공사용량이 적은 기간 동안 하루에 한 번, 필요에 따라 많이 업데이트되는 테이블을 더 자주 정리하여 보완합니다. (업데이트 속도가 매우 높은 일부 설치에서는 가장 바쁜 테이블을 몇 분에 한 번씩 진공 청소합니다.) 클러스터에 여러 데이터베이스가 있는 경우 다음을 잊지 마세요.진공각각; 프로그램vacuumdb도움이 될 것 같아요.

그포스트그레SQL쿼리 플래너는 쿼리에 대한 좋은 계획을 생성하기 위해 테이블 ​​내용에 대한 통계 정보에 의존합니다. 이 통계는 다음에 의해 수집됩니다.분석명령은 단독으로 또는 선택적 단계로 호출될 수 있습니다.진공. 합리적으로 정확한 통계를 갖는 것이 중요합니다. 그렇지 않으면 계획을 잘못 선택하면 데이터베이스 성능이 저하될 수 있습니다.

autovacuum 데몬이 활성화되면 자동으로 실행됩니다분석와이즈 토토의 내용이 충분히 변경될 때마다 명령합니다. 그러나 관리자는 수동으로 예약하는 것을 선호할 수 있습니다.분석작업, 특히 테이블의 업데이트 활동이 통계에 영향을 미치지 않는 것으로 알려진 경우“흥미롭다”열. 데몬 일정분석엄격히 삽입되거나 업데이트된 행 수의 함수입니다. 그것이 의미 있는 통계적 변화로 이어질지 여부는 알 수 없습니다.

파티션 및 상속 하위 항목에서 변경된 튜플은 상위 테이블에 대한 분석을 트리거하지 않습니다. 상위 테이블이 비어 있거나 거의 변경되지 않으면 autovacuum으로 처리되지 않을 수 있으며 상속 트리 전체에 대한 통계가 수집되지 않습니다. 실행이 필요합니다분석통계를 최신 상태로 유지하기 위해 상위 와이즈 토토에 수동으로 적용합니다.

공간 복구를 위한 진공 청소와 마찬가지로 통계를 자주 업데이트하는 것은 거의 업데이트되지 않는 테이블보다 많이 업데이트되는 테이블에 더 유용합니다. 그러나 많이 업데이트된 테이블의 경우에도 데이터의 통계적 분포가 크게 변하지 않으면 통계를 업데이트할 필요가 없을 수도 있습니다. 간단한 경험 법칙은 테이블 열의 최소값과 최대값이 얼마나 변경되는지 생각해 보는 것입니다. 예를 들어,타임스탬프행 업데이트 시간을 포함하는 열은 행이 추가되고 업데이트됨에 따라 지속적으로 증가하는 최대값을 갖습니다. 이러한 열은 웹 사이트에서 액세스하는 페이지의 URL이 포함된 열보다 더 자주 통계 업데이트가 필요할 수 있습니다. URL 열은 자주 변경사항을 수신할 수 있지만 해당 값의 통계적 분포는 비교적 느리게 변경될 수 있습니다.

실행이 가능합니다분석특정 테이블 및 테이블의 특정 열에만 적용되므로 애플리케이션에서 필요할 경우 일부 통계를 다른 통계보다 더 자주 업데이트할 수 있는 유연성이 있습니다. 그러나 실제로는 빠른 작업이기 때문에 일반적으로 전체 데이터베이스를 분석하는 것이 가장 좋습니다.분석모든 단일 행을 읽는 대신 와이즈 토토 행의 통계적으로 무작위 샘플링을 사용합니다.

진공 상태 유지토토 커뮤니티 : 문서 : 17 : 65.4. 가시성 맵각 테이블에 대해 모든 활성 트랜잭션(및 페이지가 다시 수정될 때까지 모든 향후 트랜잭션)에 표시되는 것으로 알려진 튜플만 포함된 페이지를 추적합니다. 여기에는 두 가지 목적이 있습니다. 첫째, 정리할 내용이 없기 때문에 진공 청소기 자체는 다음 실행 시 이러한 페이지를 건너뛸 수 있습니다.

둘째, 그것은 허용합니다PostgreSQL기본 와이즈 토토을 참조하지 않고 색인만 사용하여 일부 쿼리에 응답합니다. 부터PostgreSQL인덱스에는 튜플 가시성 정보가 포함되어 있지 않습니다. 일반 인덱스 스캔은 일치하는 각 인덱스 항목에 대한 힙 튜플을 가져와 현재 트랜잭션에서 표시해야 하는지 여부를 확인합니다. 안색인 전용 스캔27734_28079

PostgreSQL의와이즈 토토 : 문서 : 17 : 13.1. 소개트랜잭션 의미는 트랜잭션 ID를 비교할 수 있는지 여부에 따라 달라집니다. (XID) 숫자: 현재 트랜잭션의 XID보다 큰 삽입 XID가 있는 행 버전은“미래에”현재 트랜잭션에 표시되어서는 안 됩니다. 그러나 트랜잭션 ID의 크기는 제한되어 있으므로(32비트) 오랫동안 실행되는 클러스터(40억 개 이상의 트랜잭션)는 문제를 겪게 됩니다.거래 ID 랩어라운드: XID 카운터가 0으로 돌아가고 갑자기 과거의 트랜잭션이 미래에 있는 것처럼 보입니다. 즉, 해당 출력이 보이지 않게 됩니다. 즉, 치명적인 데이터 손실입니다. (실제로 데이터는 여전히 존재하지만, 접근할 수 없다면 불편할 것입니다.) 이를 방지하려면 적어도 20억 트랜잭션마다 한 번씩 모든 데이터베이스의 모든 테이블을 진공 청소기로 청소해야 합니다.

주기적인 진공 청소로 문제가 해결되는 이유는 다음과 같습니다.진공행을 다음으로 표시합니다동결은 삽입 트랜잭션의 효과가 모든 현재 및 미래 트랜잭션에 확실히 표시될 만큼 충분히 과거에 커밋된 트랜잭션에 의해 삽입되었음을 나타냅니다. 일반 XID는 modulo-2를 사용하여 비교됩니다.³²산술. 이는 모든 일반 XID에 대해 20억 개의 XID가 있음을 의미합니다.“이전”그리고 20억이“최신”; 다르게 말하면 일반 XID 공간은 끝점이 없는 원형이라는 것입니다. 따라서 특정 일반 XID를 사용하여 행 버전이 생성되면 행 버전은 다음과 같이 나타납니다.“과거에”우리가 말하는 일반 XID가 무엇이든 상관없이 다음 20억 개의 거래를 위해. 20억 개가 넘는 트랜잭션 후에도 행 버전이 여전히 존재한다면 갑자기 미래 버전인 것처럼 보일 것입니다. 이를 방지하기 위해,PostgreSQL특수 XID를 예약합니다.FrozenTransactionId은 일반 XID 비교 규칙을 따르지 않으며 항상 모든 일반 XID보다 오래된 것으로 간주됩니다. 고정된 행 버전은 삽입된 XID가 다음과 같이 처리됩니다.FrozenTransactionId, 그러면 다음과 같이 표시됩니다.“과거에”랩어라운드 문제에 관계없이 모든 일반 트랜잭션에 적용되므로 이러한 행 버전은 기간에 관계없이 삭제될 때까지 유효합니다.

vacuum_freeze_min_ageXID를 포함하는 행이 고정되기 전에 XID 값이 얼마나 오래되어야 하는지 제어합니다. 이 설정을 늘리면 고정될 행이 곧 다시 수정될 경우 불필요한 작업을 피할 수 있지만, 이 설정을 줄이면 테이블을 다시 정리해야 하기 전에 경과할 수 있는 트랜잭션 수가 늘어납니다.

진공다음을 사용합니다토토 커뮤니티 : 문서 : 17 : 65.4. 가시성 맵테이블의 어떤 페이지를 스캔해야 하는지 결정합니다. 일반적으로 해당 페이지에 여전히 이전 XID 값이 있는 행 버전이 있더라도 데드 행 버전이 없는 페이지는 건너뜁니다. 그러므로 정상진공s는 항상 테이블의 모든 이전 행 버전을 고정하지는 않습니다. 그런 일이 생기면,진공결국 다음을 수행해야 합니다공격적인 진공, 이는 모두 표시되지만 모두 고정되지 않은 페이지의 값을 포함하여 고정되지 않은 모든 적합한 XID 및 MXID 값을 고정합니다. 실제로 대부분의 테이블에는 정기적인 적극적인 진공 청소가 필요합니다.vacuum_freeze_table_age언제 제어진공다음을 수행합니다: 마지막 스캔 이후 통과된 트랜잭션 수가 다음보다 큰 경우 모두 표시되지만 완전히 고정되지는 않은 페이지를 스캔합니다vacuum_freeze_table_age마이너스vacuum_freeze_min_age. 환경vacuum_freeze_table_age0개의 병력에진공항상 공격적인 전략을 사용합니다.

테이블이 비워지지 않을 수 있는 최대 시간은 20억 트랜잭션에서 다음 시간을 뺀 값입니다.vacuum_freeze_min_age마지막 공격적인 진공 작업 당시의 값입니다. 그보다 오랫동안 진공 상태가 되지 않으면 데이터가 손실될 수 있습니다. 이러한 일이 발생하지 않도록 하기 위해 구성 매개변수에 지정된 기간보다 오래된 XID를 가진 고정되지 않은 행이 포함될 수 있는 모든 테이블에서 autovacuum이 호출됩니다.autovacuum_freeze_max_age. (이것은 autovacuum이 비활성화된 경우에도 발생합니다.)

이것은 테이블이 달리 진공 처리되지 않으면 대략 한 번씩 테이블에 대해 자동 진공이 호출됨을 의미합니다.autovacuum_freeze_max_age마이너스vacuum_freeze_min_age거래. 공간 회수 목적으로 정기적으로 진공 청소를 하는 테이블의 경우 이는 그다지 중요하지 않습니다. 그러나 정적 테이블(삽입을 수신하지만 업데이트나 삭제는 수행하지 않는 테이블 포함)의 경우 공간 회수를 위해 Vacuum을 수행할 필요가 없으므로 매우 큰 정적 테이블에서 강제 Autovacuum 간격을 최대화하는 것이 유용할 수 있습니다. 분명히 다음 중 하나를 증가시켜 이를 수행할 수 있습니다.autovacuum_freeze_max_age또는 감소vacuum_freeze_min_age.

다음에 대한 유효 최대값vacuum_freeze_table_age0.95 *입니다autovacuum_freeze_max_age; 그보다 높은 설정은 최대값으로 제한됩니다. 다음보다 큰 값autovacuum_freeze_max_age어쨌든 그 시점에서 랩어라운드 방지 autovacuum이 트리거되고 0.95 승수는 수동을 실행할 수 있는 숨쉴 공간을 남겨두기 때문에 의미가 없습니다.진공그 일이 일어나기 전에. 경험상,vacuum_freeze_table_age약간 낮은 값으로 설정되어야 합니다autovacuum_freeze_max_age, 정기적으로 예약될 수 있도록 충분한 간격을 둡니다.진공또는 일반적인 삭제 및 업데이트 활동에 의해 트리거된 autovacuum이 해당 창에서 실행됩니다. 너무 가깝게 설정하면 최근 공간을 확보하기 위해 테이블을 진공 처리한 경우에도 랩어라운드 방지 자동 진공이 발생할 수 있습니다. 반면 값이 낮을수록 공격적인 진공 청소가 더 자주 발생합니다.

증가의 유일한 단점autovacuum_freeze_max_age(및vacuum_freeze_table_age그리고) 그것은pg_xact그리고pg_commit_ts데이터베이스 클러스터의 하위 디렉토리는 커밋 상태와 (iftrack_commit_timestamp활성화됨) 모든 트랜잭션의 타임스탬프를 다시autovacuum_freeze_max_age수평선. 커밋 상태는 트랜잭션당 2비트를 사용하므로 다음과 같습니다.autovacuum_freeze_max_age최대 허용 값인 20억으로 설정되어 있습니다.pg_xact약 0.5GB까지 증가할 것으로 예상되며pg_commit_ts약 20GB까지. 전체 데이터베이스 크기에 비해 이것이 사소한 경우 다음을 설정하세요.autovacuum_freeze_max_age최대 허용 값으로 설정하는 것이 좋습니다. 그렇지 않으면 허용하려는 항목에 따라 설정하세요.pg_xact그리고pg_commit_ts저장. (기본값인 2억 트랜잭션은 약 50MB에 해당합니다.pg_xact저장소 및 약 2GBpg_commit_ts저장.)

감소의 한 가지 단점vacuum_freeze_min_age그것이 원인이 될 수도 있다는 것입니다진공쓸데없는 작업 수행: 행 버전을 고정하는 것은 행이 곧 수정되면(새 XID를 획득하게 만드는) 시간 낭비입니다. 따라서 설정은 행이 더 이상 변경되지 않을 때까지 행이 고정되지 않도록 충분히 커야 합니다.

데이터베이스에서 가장 오래되고 고정되지 않은 XID의 나이를 추적하려면,진공시스템 테이블에 XID 통계를 저장합니다pg_class그리고pg_database. 특히,relfrozenxid와이즈 토토의 열pg_class행에는 가장 최근의 끝에 고정되지 않은 가장 오래 남아 있는 XID가 포함됩니다.진공성공적으로 발전했습니다relfrozenxid(일반적으로 가장 최근의 공격적인 VACUUM). 마찬가지로,datfrozenxid데이터베이스의 열pg_database행은 해당 데이터베이스에 나타나는 고정되지 않은 XID의 하한입니다. 이는 테이블당 최소값일 뿐입니다.relfrozenxid데이터베이스 내의 값. 이 정보를 조사하는 편리한 방법은 다음과 같은 쿼리를 실행하는 것입니다.

c.oid::regclass를 table_name으로 선택하고,
       가장 큰(age(c.relfrozenxid),age(t.relfrozenxid))(나이)
pg_class c에서
왼쪽 조인 pg_class t ON c.reltoastrelid = t.oid
WHERE c.relkind IN ('r', 'm');

pg_database에서 datname, age(datfrozenxid) 선택;

그나이열은 컷오프 XID부터 현재 트랜잭션의 XID까지의 트랜잭션 수를 측정합니다.

진공일반적으로 마지막 진공 이후 수정된 페이지만 검색하지만relfrozenxid고정 해제된 XID를 포함할 수 있는 테이블의 모든 페이지를 검사할 때만 고급화할 수 있습니다. 이런 경우가 발생합니다.relfrozenxid이상vacuum_freeze_table_age오래된 거래, 언제진공's정지옵션이 사용되거나 아직 완전히 고정되지 않은 모든 페이지가 데드 행 버전을 제거하기 위해 진공 청소가 필요한 경우입니다. 언제진공아직 완전히 고정되지 않은 와이즈 토토의 모든 페이지를 검색합니다. 설정되어야 합니다.나이(relfrozenxid)값보다 조금 더 높은 값으로vacuum_freeze_min_age사용된 설정(이후 시작된 트랜잭션 수에 따라 더 많음진공시작됨).진공설정할 것입니다relfrozenxid테이블에 남아 있는 가장 오래된 XID로 변경되므로 최종 값은 엄격하게 요구되는 것보다 훨씬 더 최근 값이 될 가능성이 있습니다. 그렇지 않은 경우relfrozenxid-전진 중진공다음까지 테이블에 발행됩니다.autovacuum_freeze_max_age도달하면 곧 테이블에 자동 진공이 강제 실행됩니다.

어떤 이유로 autovacuum이 테이블에서 이전 XID를 지우지 못하는 경우 데이터베이스의 가장 오래된 XID가 랩어라운드 지점에서 4천만 트랜잭션에 도달하면 시스템은 다음과 같은 경고 메시지를 보내기 시작합니다.

경고: 데이터베이스 "mydb"는 39985967 트랜잭션 내에서 비워져야 합니다
힌트: XID 할당 실패를 방지하려면 해당 데이터베이스에서 데이터베이스 전체 VACUUM을 실행하세요.

(설명서진공힌트에서 제안한 대로 문제를 해결해야 합니다. 하지만 참고하세요.진공수퍼유저가 수행해야 합니다. 그렇지 않으면 시스템 카탈로그 처리에 실패하여 데이터베이스의 고급 기능을 수행할 수 없게 됩니다.datfrozenxid.) 이러한 경고를 무시하면 랩어라운드까지 남은 트랜잭션이 300만 개 미만이면 시스템은 새 XID 할당을 거부합니다.

오류: 데이터베이스는 "mydb" 데이터베이스의 랩어라운드 데이터 손실을 방지하기 위해 새 XID를 할당하는 명령을 허용하지 않습니다.
힌트: 해당 데이터베이스에서 데이터베이스 전체 VACUUM을 실행하세요.

이 조건에서는 이미 진행 중인 모든 트랜잭션을 계속할 수 있지만 읽기 전용 트랜잭션만 시작할 수 있습니다. 데이터베이스 레코드를 수정하거나 관계를 자르는 작업은 실패합니다. 그만큼진공명령은 여전히 ​​정상적으로 실행될 수 있습니다. 이전 릴리스에서 때때로 권장되었던 것과는 달리, 정상 작동을 복원하기 위해 포스트마스터를 중지하거나 단일 사용자 모드로 들어가는 것은 필요하지도 바람직하지도 않습니다. 대신 다음 단계를 따르세요.

PostgreSQL선택사항이지만 적극 권장되는 기능이 있습니다.자동 진공, 그 목적은 다음의 실행을 자동화하는 것입니다.진공그리고분석명령. 활성화되면 autovacuum은 삽입, 업데이트 또는 삭제된 튜플이 많이 있는 테이블을 확인합니다. 이러한 검사에서는 통계 수집 기능을 사용합니다. 따라서 autovacuum은 다음을 제외하고는 사용할 수 없습니다.track_counts다음으로 설정됨참. 기본 구성에서는 autovacuuming이 활성화되고 관련 구성 매개변수가 적절하게 설정됩니다.

그“autovacuum 데몬”실제로는 여러 프로세스로 구성됩니다. 다음과 같은 지속적인 데몬 프로세스가 있습니다.자동 진공 실행기, 시작을 담당하는자동 진공 작업자모든 데이터베이스에 대한 프로세스입니다. 런처는 시간에 따라 작업을 분산하여 매 데이터베이스 내에서 하나의 작업자를 시작하려고 시도합니다.autovacuum_naptime초. (따라서 설치가 완료된 경우)N데이터베이스마다 새로운 작업자가 시작됩니다.autovacuum_naptime/N초.) 최대autovacuum_max_workers작업자 프로세스가 동시에 실행될 수 있습니다. 개 이상인 경우autovacuum_max_workers데이터베이스를 처리할 경우 첫 번째 작업자가 완료되자마자 다음 데이터베이스가 처리됩니다. 각 작업자 프로세스는 데이터베이스 내의 각 테이블을 확인하고 실행합니다.진공및/또는분석필요에 따라.log_autovacuum_min_durationautovacuum 작업자의 활동을 모니터링하도록 설정할 수 있습니다.

몇 개의 큰 테이블이 짧은 시간 내에 모두 진공 청소 대상이 되면 모든 자동 진공 작업자는 오랜 기간 동안 해당 테이블을 진공 청소하는 데 전념할 수 있습니다. 이로 인해 작업자가 사용 가능해질 때까지 다른 테이블과 데이터베이스가 정리되지 않습니다. 단일 데이터베이스에 포함될 수 있는 작업자 수에는 제한이 없지만 작업자는 다른 작업자가 이미 수행한 작업을 반복하지 않으려고 노력합니다. 실행 중인 작업자 수는 계산에 포함되지 않습니다.max_connections또는superuser_reserved_connections한계.

다음 테이블relfrozenxid값이 다음보다 큼autovacuum_freeze_max_age오래된 트랜잭션은 항상 비워집니다(이는 저장 매개변수를 통해 동결 최대 기간이 수정된 테이블에도 적용됩니다. 아래 참조). 그렇지 않은 경우 마지막 이후로 사용되지 않는 튜플의 수가 있는 경우진공초과“진공 임계값”, 테이블이 진공청소되었습니다. 진공 임계값은 다음과 같이 정의됩니다.

진공 임계값 = 진공 기본 임계값 + 진공 배율 인수 * 튜플 수

여기서 진공 베이스 임계값은autovacuum_vacuum_threshold, 진공 스케일 팩터는autovacuum_vacuum_scale_factor, 튜플 수는pg_class.reltuples.

마지막 진공 이후 삽입된 튜플의 수가 정의된 삽입 임계값을 초과한 경우에도 테이블이 진공 처리됩니다. 이는 다음과 같이 정의됩니다.

진공 삽입 임계값 = 진공 기본 삽입 임계값 + 진공 삽입 배율 인수 * 튜플 수

여기서 진공 인서트 베이스 임계값은autovacuum_vacuum_insert_threshold, 진공 삽입 배율 계수는autovacuum_vacuum_insert_scale_factor. 이러한 진공청소기를 사용하면 테이블의 일부에 다음과 같이 표시될 수 있습니다.모두 표시됨또한 튜플을 고정할 수 있으므로 후속 진공 작업에 필요한 작업이 줄어들 수 있습니다. 수신하는 테이블의 경우삽입작업은 수행되지만 수행되지 않거나 거의 수행되지 않음업데이트/삭제작업, 와이즈 토토의 높이를 낮추는 것이 도움이 될 수 있습니다autovacuum_freeze_min_age이로 인해 튜플이 이전 진공에 의해 고정될 수 있기 때문입니다. 사용되지 않는 튜플 수와 삽입된 튜플 수는 누적 통계 시스템에서 가져옵니다. 이는 각각에 의해 업데이트되는 최종적으로 일관된 개수입니다.업데이트, 삭제그리고삽입작업. 만약relfrozenxid테이블 값이 다음보다 큽니다.vacuum_freeze_table_age오래된 트랜잭션, 오래된 튜플을 동결하고 진행하기 위해 공격적인 진공이 수행됩니다.relfrozenxid; 그렇지 않으면 마지막 진공 작업 이후 수정된 페이지만 스캔됩니다.

분석을 위해 유사한 조건이 사용됩니다: 임계값은 다음과 같이 정의됩니다.

임계값 분석 = 기본 임계값 분석 + 배율 인자 분석 * 튜플 수

마지막 이후 삽입, 업데이트 또는 삭제된 총 튜플 수와 비교됩니다.분석.

분할된 테이블은 튜플을 직접 저장하지 않으므로 결과적으로 autovacuum으로 처리되지 않습니다. (Autovacuum은 다른 테이블과 마찬가지로 테이블 파티션을 처리합니다.) 안타깝게도 이는 autovacuum이 실행되지 않음을 의미합니다.분석파티션된 테이블에서 발생하며 이로 인해 파티션된 테이블 통계를 참조하는 쿼리에 대해 최적이 아닌 계획이 발생할 수 있습니다. 수동으로 실행하여 이 문제를 해결할 수 있습니다.분석파티션된 테이블이 처음 채워질 때, 그리고 파티션의 데이터 분포가 크게 변경될 때마다 다시 발생합니다.

임시 테이블은 autovacuum으로 접근할 수 없습니다. 따라서 세션 SQL 명령을 통해 적절한 진공화 및 분석 작업을 수행해야 합니다.

기본 임계값 및 배율 인수는 다음에서 가져옵니다.postgresql.conf, 그러나 테이블별로 해당 항목(및 기타 여러 autovacuum 제어 매개변수)을 재정의할 수 있습니다. 보다저장 매개변수60023_60203사설 토토 사이트 : 문서 : 17 : 19.10. 사설 토토 사이트 진공 사설 토토 사이트전역 설정에 대한 자세한 내용을 확인하세요.

여러 작업자가 실행 중일 때 자동 진공화 비용 지연 매개변수(참조섹션 19.4.4)는“균형 잡힌”실행 중인 모든 작업자 중에서 시스템에 대한 총 I/O 영향은 실제로 실행 중인 작업자 수에 관계없이 동일합니다. 그러나 테이블당 테이블을 처리하는 모든 작업자는autovacuum_vacuum_cost_delay또는autovacuum_vacuum_cost_limit설정된 저장 매개변수는 밸런싱 알고리즘에서 고려되지 않습니다.

Autovacuum 작업자는 일반적으로 다른 명령을 차단하지 않습니다. 프로세스가 다음과 충돌하는 잠금을 획득하려고 시도하는 경우업데이트 독점 공유autovacuum에 의해 잠금이 유지됩니다. 잠금 획득으로 인해 autovacuum이 중단됩니다. 잠금 모드 충돌에 대해서는 다음을 참조하세요.표 13.2. 그러나 트랜잭션 ID 랩어라운드를 방지하기 위해 autovacuum이 실행 중인 경우(즉,pg_stat_activity보기는 다음으로 끝납니다.(랩어라운드 방지를 위해)), autovacuum은 자동으로 중단되지 않습니다.