PostgreSQL에서는 특정 명령이 실행 되고 있는 동안
그 작업의 진행 상태를 살펴 볼 수 있다. 이 기능은 현재
CREATE INDEX,
VACUUM,
CLUSTER 명령에 대해서만 사용할 수 있다. 앞으로
계속 추가 될 것이다.
Whenever CREATE INDEX or REINDEX is running, the
pg_stat_progress_create_index view will contain
one row for each backend that is currently creating indexes. The tables
below describe the information that will be reported and provide information
about how to interpret it.
표 27.22. pg_stat_progress_create_index View
| Column | Type | Description |
|---|---|---|
pid | integer | Process ID of backend. |
datid | oid | OID of the database to which this backend is connected. |
datname | name | Name of the database to which this backend is connected. |
relid | oid | OID of the table on which the index is being created. |
index_relid | oid | OID of the index being created or reindexed. During a
non-concurrent CREATE INDEX, this is 0. |
command | text |
The command that is running: CREATE INDEX,
CREATE INDEX CONCURRENTLY,
REINDEX, or REINDEX CONCURRENTLY.
|
phase | text | Current processing phase of index creation. See 표 27.23. |
lockers_total | bigint | Total number of lockers to wait for, when applicable. |
lockers_done | bigint | Number of lockers already waited for. |
current_locker_pid | bigint | Process ID of the locker currently being waited for. |
blocks_total | bigint | Total number of blocks to be processed in the current phase. |
blocks_done | bigint | Number of blocks already processed in the current phase. |
tuples_total | bigint | Total number of tuples to be processed in the current phase. |
tuples_done | bigint | Number of tuples already processed in the current phase. |
partitions_total | bigint | When creating an index on a partitioned table, this column is set to the total number of partitions on which the index is to be created. |
partitions_done | bigint | When creating an index on a partitioned table, this column is set to the number of partitions on which the index has been completed. |
표 27.23. CREATE INDEX Phases
| Phase | Description |
|---|---|
initializing |
CREATE INDEX or REINDEX is preparing to create the index. This
phase is expected to be very brief.
|
waiting for writers before build |
CREATE INDEX CONCURRENTLY or REINDEX CONCURRENTLY is waiting for transactions
with write locks that can potentially see the table to finish.
This phase is skipped when not in concurrent mode.
Columns lockers_total, lockers_done
and current_locker_pid contain the progress
information for this phase.
|
building index |
The index is being built by the access method-specific code. In this phase,
access methods that support progress reporting fill in their own progress data,
and the subphase is indicated in this column. Typically,
blocks_total and blocks_done
will contain progress data, as well as potentially
tuples_total and tuples_done.
|
waiting for writers before validation |
CREATE INDEX CONCURRENTLY or REINDEX CONCURRENTLY is waiting for transactions
with write locks that can potentially write into the table to finish.
This phase is skipped when not in concurrent mode.
Columns lockers_total, lockers_done
and current_locker_pid contain the progress
information for this phase.
|
index validation: scanning index |
CREATE INDEX CONCURRENTLY is scanning the index searching
for tuples that need to be validated.
This phase is skipped when not in concurrent mode.
Columns blocks_total (set to the total size of the index)
and blocks_done contain the progress information for this phase.
|
index validation: sorting tuples |
CREATE INDEX CONCURRENTLY is sorting the output of the
index scanning phase.
|
index validation: scanning table |
CREATE INDEX CONCURRENTLY is scanning the table
to validate the index tuples collected in the previous two phases.
This phase is skipped when not in concurrent mode.
Columns blocks_total (set to the total size of the table)
and blocks_done contain the progress information for this phase.
|
waiting for old snapshots |
CREATE INDEX CONCURRENTLY or REINDEX CONCURRENTLY is waiting for transactions
that can potentially see the table to release their snapshots. This
phase is skipped when not in concurrent mode.
Columns lockers_total, lockers_done
and current_locker_pid contain the progress
information for this phase.
|
waiting for readers before marking dead |
REINDEX CONCURRENTLY is waiting for transactions
with read locks on the table to finish, before marking the old index dead.
This phase is skipped when not in concurrent mode.
Columns lockers_total, lockers_done
and current_locker_pid contain the progress
information for this phase.
|
waiting for readers before dropping |
REINDEX CONCURRENTLY is waiting for transactions
with read locks on the table to finish, before dropping the old index.
This phase is skipped when not in concurrent mode.
Columns lockers_total, lockers_done
and current_locker_pid contain the progress
information for this phase.
|
VACUUM 명령이 실행 될 때마다,
pg_stat_progress_vacuum 뷰에
하나의 로우 단위로 각 개별 작업에 대한 진행 상태를
보관한다. (autovacuum 작업자 프로세스도 포함한다.)
이 뷰의 각 칼럼에 대한 설명과 그 값을 어떻게 해석할 것인가는
아래에서 다룬다.
VACUUM FULL 작업에 대해서는
pg_stat_progress_cluster 뷰를
통해 살펴볼 수 있다.
VACUUM FULL 작업과 CLUSTER
작업은 둘 다 테이블을 새로 만드는 작업이기 때문이다.
일반 VACUUM 작업은 테이블 내용을 바꾸는 작업으로
이것들과 구분된다. 27.4.3절 참조.
표 27.24. pg_stat_progress_vacuum 뷰
| 칼럼 | 자료형 | 설명 |
|---|---|---|
pid | integer | 해당 PID |
datid | oid | 해당 프로세스가 접속한 데이터베이스 OID |
datname | name | 해당 프로세스가 접속한 데이터베이스 이름 |
relid | oid | 현재 vacuum 작업 중인 테이블 OID |
phase | text | 현재 진행 상태. 표 27.25 참조. |
heap_blks_total | bigint |
테이블의 힙 블럭 전체 수량. 이 숫자는 테이블 탐색 작업
시작 때 결정된다. VACUUM 작업 진행 과정
속에서 추가 되거나 삭제되는 블럭에 대해서는 고려하지 않는다.
|
heap_blks_scanned | bigint |
탐색한 힙 블럭 수. 탐색 최적화를 위해서
visibility map을 이용하기 때문에,
vacuum 대상 블럭인지 조사하는 작업을 몇몇 블럭에서 하지 않을
수도 있다. 이렇게 건너뛴 블럭도 이 수에 모두 포함한다. 이렇게
해서 이 수가 heap_blks_total 수와 같으면,
vacuum 작업이 완료된 것이다. 이 수는 scanning heap
상태에서만 증가한다.
|
heap_blks_vacuumed | bigint |
vacuum 작업을 한 힙 블럭 수. 테이블에 인덱스가 없다면,
이 수는 vacuuming heap 상태에서만 증가한다. 더 이상
사용하지 않는 자료(dead tuple)가 없는 블럭에 대해서는 건너
뛰기 때문에 이 수는 한꺼번에 많은 수가 증가 할 수도 있다.
|
index_vacuum_count | bigint | vacuum 작업이 완료된 인덱스 수 |
max_dead_tuples | bigint | 인덱스 vacuum 작업을 수행해야 할 경우 고려해야할 dead tuple 수 이 수는 maintenance_work_mem 환경 설정값에 기초한다. |
num_dead_tuples | bigint | 인덱스 vacuum 작업으로 처리한 dead tuple 수 |
표 27.25. VACUUM 상태
| 상태 | 설명 |
|---|---|
initializing |
VACUUM 탐색 작업 초기화 중.
이 상태는 순십간에 지나갈 것이다.
|
scanning heap |
VACUUM 작업이 테이블 탐색 중. 각 블럭을 청소하고,
필요하다면, 블럭을 버리는 작업, 또는 자료 영구 보관 작업까지
진행한다. 한 블럭 작업이 마무리 할 때마다
heap_blks_scanned 칼럼 값이 증가된다.
|
vacuuming indexes |
VACUUM 작업이 인덱스 청소 중.
테이블에 인덱스가 있다면, 이 상태는 테이블 탐색이 끝난 뒤
한 번 나타난다.
maintenance_work_mem 설정값이 충분히 크지 않아
모든 dead tuple을 한 번에 처리할 수 없다면,
한 번의 vacuum 작업에서 여러번 나타날 수도 있다.
|
vacuuming heap |
VACUUM 작업이 테이블 힙을 청소 중. 청소 작업은
힙 탐색 작업과 다르며, 인덱스 청소 작업 뒤에 한 번 나타난다.
만일 heap_blks_scanned 수가
heap_blks_total 수보다 적다면,
이 상태 다음에 힙 탐색 상태가 되며,
그렇지 않다면, 인덱스 정리 상태로 넘어간다.
|
cleaning up indexes |
VACUUM 작업에서 인덱스들을 정리 하는 중. 이 상태는
힙 탐색이 끝났고, 모든 인덱스와 힙의 정리 작업도 끝난 다음에 나타난다.
|
truncating heap |
VACUUM 작업에서 해당 테이블 끝 부분에 있는 비어있는 블럭을
OS로 반환하는 작업 상태. 이 상태는 인덱스 정리 작업 다음에 나타난다.
|
performing final cleanup |
VACUUM 최종 마무리 단계. 이 상태에서는
VACUUM 작업은 여유 공간 지도 파일을 정리하고,
pg_class의 통계 정보를 갱신하고, 통계 수집기로
통계 정보를 보낸다. 이 상태가 끝나면, VACUUM
작업은 끝난다.
|
Whenever CLUSTER or VACUUM FULL is
running, the pg_stat_progress_cluster view will
contain a row for each backend that is currently running either command.
The tables below describe the information that will be reported and
provide information about how to interpret it.
표 27.26. pg_stat_progress_cluster View
| Column | Type | Description |
|---|---|---|
pid | integer | Process ID of backend. |
datid | oid | OID of the database to which this backend is connected. |
datname | name | Name of the database to which this backend is connected. |
relid | oid | OID of the table being clustered. |
command | text |
The command that is running. Either CLUSTER or VACUUM FULL.
|
phase | text | Current processing phase. See 표 27.27. |
cluster_index_relid | oid | If the table is being scanned using an index, this is the OID of the index being used; otherwise, it is zero. |
heap_tuples_scanned | bigint |
Number of heap tuples scanned.
This counter only advances when the phase is
seq scanning heap,
index scanning heap
or writing new heap.
|
heap_tuples_written | bigint |
Number of heap tuples written.
This counter only advances when the phase is
seq scanning heap,
index scanning heap
or writing new heap.
|
heap_blks_total | bigint |
Total number of heap blocks in the table. This number is reported
as of the beginning of seq scanning heap.
|
heap_blks_scanned | bigint |
Number of heap blocks scanned. This counter only advances when the
phase is seq scanning heap.
|
index_rebuild_count | bigint |
Number of indexes rebuilt. This counter only advances when the phase
is rebuilding index.
|
표 27.27. CLUSTER and VACUUM FULL Phases
| Phase | Description |
|---|---|
initializing | The command is preparing to begin scanning the heap. This phase is expected to be very brief. |
seq scanning heap | The command is currently scanning the table using a sequential scan. |
index scanning heap |
CLUSTER is currently scanning the table using an index scan.
|
sorting tuples |
CLUSTER is currently sorting tuples.
|
writing new heap |
CLUSTER is currently writing the new heap.
|
swapping relation files | The command is currently swapping newly-built files into place. |
rebuilding index | The command is currently rebuilding an index. |
performing final cleanup |
The command is performing final cleanup. When this phase is
completed, CLUSTER
or VACUUM FULL will end.
|