통계 자료를 수집한다는 것은 궁극적으로는 그 만큼의 추가 비용을 서버가 사용한다는 것을 의미한다. 그래서, 그 추가 비용을 얼마만큼 쓸 것인지에 대한 결정을 서버 환경변수로 제어할 수 있다. 다음은 postgresql.conf 환경설정 파일에서 사용할 수 있는 환경변수들이다. (이들에 대한 보다 자세한 부분은 19장을 참고하라.)

track_activities 설정값을 활성화하면 각각의 서버 프로세스들은 현재 자신이 하고 있는 작업을 프로세스 이름으로 보여준다.

track_counts 설정값을 활성화하면 테이블과 인덱스의 사용빈도를 통계 수집기가 수집한다.

track_functions 설정값을 활성화하면 사용자 정의 함수들의 사용빈도를 통계 수집기가 수집한다.

track_io_timing 설정값을 활성화면 블록 읽기 쓰기 회수를 통계 수집기가 수집한다.

일반적으로 이 환경설정 변수들은 postgresql.conf에서 그 값을 지정하면, 이것은 모든 서버의 프로세스들을 대상으로 작동하게 된다. 하지만, SET 명령을 이용해서, 개별 세션 단위로 이 설정값을 변경할 수도 있다. (이 작업은 일반 사용자가 악의적으로 사용될 가능성이 있기 때문에, 슈퍼유저만 사용할 수 있다.)

통계 수집기가 만든 정보는 stats_temp_directory 설정값으로 지정한 디렉터리 (초기값은 pg_stat_tmp) 안에 있는 임시파일로 저장되고, 그것을 여러 다른 PostgreSQL 프로세스들이 이용한다. 보다 나은 성능을 위해서는 이 파일의 I/O 성능을 높이기 위해 이 디렉터리를 메모리 기반 파일시스템에 두는 것도 좋은 방법이다. 이 통계 정보는 서버가 중지 될 때 pg_stat 디렉터리 쪽으로 복사하는 작업을 하기 때문에, 서버 중지, 재시작에도 자료를 그대로 유지할 수 있다.

위에서 설명한 시스템의 현재 상태는 표 28.1 뷰들을 통해서 살펴볼 수 있고, 그 외 수집된 통계 정보는 아래 표 28.2에서 나열한 여러 뷰를 통해서 살펴 볼 수 있다. 다른 방법으로는 28.2.3절에서 제공하는 여러 통계 정보 보기 함수들을 이용해서 필요한 뷰를 직접 만들어서 살펴 볼 수도 있을 것이다.

여기서 중요한 점은 살펴 보고 있는 수집된 통계 정보는 현재 데이터베이스의 정확한 현재 상태가 아니라는 점이다. 각 개별 프로세스들이 수집한 통계 정보는 그 프로세스가 아무런 작업을 하고 있지 않을 때, 수집기에게 전달한다. 즉 한 쿼리가 실행 되고 있다거나 트랜잭션 내에 있다면, 그 과정에 생긴 통계 정보들은 반영되지 않고 있다는 것이다. 또한 통계 수집기의 작업은 PGSTAT_STAT_INTERVAL (기본값은 500ms 이다) 시간 간격으로 진행된다. 즉 이 만큼의 통계 정보 오차가 발생한다. 하지만, track_activities 관련 정보는 항상 즉시 반영 된다.

또 다른 중요한 점은 한 통계 정보는 해당 뷰나, 함수로 출력할 때, 한 트랜잭션 내에서는 항상 같은 값을 출력한다. 즉, 트랜젹션이 끝날 때까지 그 값을 유지한다. 이와 비슷하게 모든 세션들의 현재 쿼리에 대한 정보도 하나의 트랜잭션 내에서는 같은 정보를 출력한다. 이것은 버그가 아니라 특성이다. 이것은 한 트랜잭션 내에서 그 통계 정보가 일정하게 유지 되도록해서 여러 다른 쿼리들에서 그 값을 일관성 있게 한다. 하지만 이것을 원치 않는다면 각 쿼리들을 트랜잭션 단위로 분리해서 작업하면 된다. 다른 방법으로 pg_stat_clear_snapshot() 함수를 사용해서, 현재 스냅숏으로 지정된 통계 정보를 버리고 새 통계 정보를 사용할 수도 있다.

하나의 트랜잭션 내에서 그 자신의 통계 정보 (아직까지 수집기 쪽으로 보내지 않은 현재 작업 내역에 대한 정보)들은 다음과 같은 뷰에서 제공한다: pg_stat_xact_all_tables, pg_stat_xact_sys_tables, pg_stat_xact_user_tables, pg_stat_xact_user_functions. 이들의 통계 정보는 현재 트랜잭션 내에서도 자신의 세션 작업에 대한 통계치를 반영 해서 다른 세션에서 수집된 정보와 자신의 세션에서 수집된 정보와 차이가 생길 수도 있다.

인덱스 별 통계 정보는 어느 인덱스가 많이 사용되며, 어떻게 영향을 미치는 지를 조사하는데 특히 유용하게 쓰인다.

pg_statio_ 뷰들은 공유 버퍼의 사용 빈도를 파악하는데 가장 기본이 되는 것들이다. 이상적인 서버 운영 모습은 디스크 읽기 빈도 보다 공유 버퍼를 사용하는(buffer hit) 빈도가 훨씬 높아서, 대부분의 작업이 커널 호출 작업 없이 이루워 지도록 하는 것이다. 한편, PostgreSQL 에서는 단지 이 서버 기준으로 디스크를 읽은 것과 서버의 공유 버퍼를 사용한 것에 대한 정보만 제공 할 뿐이다. 즉, 커널의 I/O 캐시 사용 빈도에 대해서는 제공하지 않는다. 다시 말하면, 정말 디스크를 읽은 것인지, OS의 I/O 캐시를 사용한 것인지는 이 뷰를 통해서는 알 수 없다. 이런 세세한 부분까지 살펴 보려면, OS 관련 도구들을 이용해야 할 것이다.

pg_stat_activity 뷰는 서버 프로세스당 한 개의 로우를 가지며 이는 해당 프로세스의 현재 활동 관련 정보를 보여준다.

Here is an example of how wait events can be viewed

SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event is NOT NULL;
 pid  | wait_event_type |  wait_event
------+-----------------+---------------
 2540 | Lock            | relation
 6644 | LWLock          | ProcArrayLock
(2 rows)

pg_stat_replication뷰는 WAL 송신자 프로세스당 하나의 로우를 가지며, 송신자가 연결된 대기 서버의 리플리케이션에 관한 통계치를 보여준다. 직접 연결된 대기 서버만 보여진다. 다운스트림 대기 서버에 관한 정보는 없다.

The lag times reported in the pg_stat_replication view are measurements of the time taken for recent WAL to be written, flushed and replayed and for the sender to know about it. These times represent the commit delay that was (or would have been) introduced by each synchronous commit level, if the remote server was configured as a synchronous standby. For an asynchronous standby, the replay_lag column approximates the delay before recent transactions became visible to queries. If the standby server has entirely caught up with the sending server and there is no more WAL activity, the most recently measured lag times will continue to be displayed for a short time and then show NULL.

Lag times work automatically for physical replication. Logical decoding plugins may optionally emit tracking messages; if they do not, the tracking mechanism will simply display NULL lag.

The pg_stat_wal_receiver view will contain only one row, showing statistics about the WAL receiver from that receiver's connected server.

The pg_stat_subscription view will contain one row per subscription for main worker (with null PID if the worker is not running), and additional rows for workers handling the initial data copy of the subscribed tables.

The pg_stat_ssl view will contain one row per backend or WAL sender process, showing statistics about SSL usage on this connection. It can be joined to pg_stat_activity or pg_stat_replication on the pid column to get more details about the connection.

pg_stat_archiver 뷰는 클러스터의 아카이버 프로세스에 관한 데이터가 있는 하나의 로우만 갖고 있다.

pg_stat_bgwriter 뷰는 항상 한 개의 로우만 보여준다. 이 자료는 데이터클러스터 전역 정보다.

pg_stat_database 뷰는 클러스터 내 데이터베이스 당 한 개의 로우를 가지며 전체 데이터베이스 통계치를 보여준다.

pg_stat_database_conflicts 뷰는 데이터베이스당 하나의 로우를 가지며, 대기 서버의 복구 충돌로 인해 발생한 쿼리 취소에 대해 전체 데이터베이스 통계치를 보여준다. 마스터 서버에서 충돌이 발생하지 않으므로 이 뷰는 대기 서버의 정보만 갖고 있다.

pg_stat_all_tables 뷰는 현재 데이터베이스의 테이블(TOAST 테이블 포함)당 한 개의 로우를 가지며, 이는 해당 테이블 접근에 대한 통계치를 보여준다. pg_stat_user_tables와 pg_stat_sys_tables뷰는 같은 정보를 가지나 사용자와 시스템 테이블 각각을 보여주는 데만 쓰인다.

pg_stat_all_indexes 뷰는 현재 데이터베이스에서 인덱스 당 한 개의 로우를 가지며 해당 인덱스 접근에 대한 통계치를 보여준다. pg_stat_user_indexes와 pg_stat_sys_indexes 뷰는 같은 정보를 갖지만 각각 사용자와 시스템 인덱스만 보여준다.

인덱스는 단순한 인덱스 스캔, “bitmap” 인덱스 스캔, 쿼리 최적화기에서 사용된다. 비트맵 스캔에서 일부 인덱스 결과는 AND나 OR 규칙으로 통합될 수 있어서, 비트맵 스캔이 사용되면 각각의 heap 로우들을 특정 인덱스에 매칭하기 어렵다. 비트맵 스캔은 사용된 인덱스의 pg_stat_all_indexes.idx_tup_read 를 증가시키고, 테이블의 pg_stat_all_tables.idx_tup_fetch 를 증가시키지만 pg_stat_all_indexes.idx_tup_fetch에는 영향을 미치지 않는다. The optimizer also accesses indexes to check for supplied constants whose values are outside the recorded range of the optimizer statistics because the optimizer statistics might be stale.

pg_statio_all_tables 뷰는 현재 데이터베이스에서 각 테이블당(TOAST 테이블을 포함해서) 한 개의 로우를 갖는데, 해당 테이블의 I/O에 대한 통계치를 보여준다. pg_statio_user_tables와 pg_statio_sys_tables 뷰도 같은 정보를 갖지만 각기 사용자와 시스템 테이블만 보여준다.

pg_statio_all_indexes뷰는 현재 데이터베이스의 각 인덱스당 하나의 로우를 갖는데, 해당 인덱스의 I/O에 대한 통계치를 보여준다. pg_statio_user_indexes와 pg_statio_sys_indexes 뷰도 같은 정보를 갖지만 사용자와 시스템 인덱스만 각각 보여준다.

pg_statio_all_sequences 뷰는 현재 데이터베이스의 각 시퀀스당 한 개의 로우를 갖고, 해당 시퀀스의 I/O에 대한 통계치를 보여준다.

pg_stat_user_functions 뷰는 추적된 각 함수당 한 개의 로우를 가지며, 함수 수행에 대한 통계치를 보여 준다. track_functions는 정확히 어떤 함수가 추적되어야 하는지 정한다.

위에서 소개한 뷰를 통해서 서버 통계 정보를 살펴보는 방법과 함께 또 다른 한 방법은 각각의 정보를 제공하는 함수를 사용하는 방법이다. 위에서 소개한 뷰들의 뷰 정의를 살펴보면, 각각의 뷰가 어떤 함수들을 사용하는지 알 수 있다. (예를 들면, psql 에서 \d+ pg_stat_activity 명령을 사용하면 된다.) 데이터베이스 단위로 통계 정보를 보여주는 함수들에 대해서는 함수의 입력 인자로 데이터베이스 OID를 입력해야 한다. 이처럼, 테이블별, 인덱스별, 함수별 통계 정보를 살펴보려면, 그 각 객체의 OID를 입력 인자로 사용하면 된다. 기억해야 할 점은, 테이블, 인덱스, 함수 같은 각 데이터베이스 소속 객체들을 입력 인자로 쓰는 함수라면, 그 데이터베이스는 현재 접속한 데이터베이스가 된다.

부가적으로 제공하는 통계 관련 함수들은 표 28.19에서 소개한다.

pg_stat_activity 뷰에서 사용되는 pg_stat_get_activity 함수는 지정한 한 세션의 현재 상태에 대한 모든 정보를 레코드 자료형으로 리턴한다. 이렇게, 가끔은 뷰보다, 함수를 직접 사용하는 것이 보다 유용할 때가 있다. 위에서 소개한 뷰들(표 28.20)은 함수를 호출하고 그것을 뷰로 보여주기 때문에, 뷰를 내용으로 출력 되는 결과는 이미 지난 자료 집합이다 보다 정확한 현재 상태를 파악 하고자 할 때, 이런 함수를 직접 사용하는 방법이 좋다. 한 예제를 소개하면, 다음은, 현재 접속해 있는 세션들의 PID와 현재 실행 중인 쿼리 내용을 보는 쿼리다:

SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
       pg_stat_get_backend_activity(s.backendid) AS query
    FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;