pg_stat_*_tables 의 뷰에서 앞부분 테이블 전체 순차 탐색은 몇번했고, 인덱스 탐색은 몇 번 했고, 이런 것들은 해당 인스턴스 한정이고, 

그 뒤로 이어 나오는 n_으로 시작하는 모든 칼럼과 끝부분 나오는 vacuum과 analyze 관련 정보는 

읽기 쓰기 가능한 운영 인스턴스의 vacuum과 analyze 를 위한 정보입니다. 

즉 n_live_tup 값을 운영 전환해서 사용하겠다는 생각은 아주 위험합니다. 

대안으로 analyze 작업이 끝나면, pg_class.reltuples 값을 갱신합니다. 이 값으로 대강 추정은 할 수 있습니다. 

물론 analyze 가 선행 되어야하면, analyze 샘플링 대상이 적으면 그 품질도 떨어지겠죠. 

대기 인스턴스가 운영 인스턴스로 바뀌고 난 뒤에는 autovacuum 작업이 잘 될 수 있도록 analyze & vacuum 작업이 필수겠네요.

switch over 되었을 때 통계 생각은 못해봤네요. 

예전에 문의해보니, 조회전용으로 쓸 경우, replication 통계는 거의

master 와 동일할겁니다라는 말만 들었거든요. 

아직도 replication 조회시 실행계획이 어떤 통계를 바탕으로 나오는지는 모르겠습니다. 

다만, switch over 되었을 때 통계는 생각해볼만하네요. 

통계정보 export / import 가 되는 DB 도 있죠. 

이런 기능이 있으면 좋을 것 같다는 생각이 되네요. 

적어도 건수, 카디널리티, 인덱스 기초 정보만 있어도 실행계획 만드는 것은 가능 할 것 같긴한데 

master - slave 의 기초 통계 정보는 공유했으면 좋을 것 같다는 생각이 듭니다. 

postgresql 의 경우는 통계정보가 최신일수록 성능이 좋은 것 같습니다. 

(vacuum analyze) 

pg_statistic 저장된 자료를 기반으로 실행계획을 짭니다. 

이 자료는 시스템 테이블이기 때문에, analyze 작업으로 갱신되고, 복제됩니다. 

대기 서버가 운영 서버로 전환된 뒤에 문제가 바로 저 autovacuum 이겠네요. 

이론적으로만 생각하면, 이도 vacuum 과 analyze 관련도 어떻게든 기본 설정값으로 테이블의 내용이 바뀌면 어떻게든 돌아서 기존 운영 환경가 같게 맞출 것 같습니다. 

단지, 인스턴스가 실행된 뒤 벌어졌던 각종 누계정보들이 초기화 되어 연속성을 가진 어떤 수집 자료를 만드는데 문제가 생기겠네요. 

pg_stat_bgwriter 정보들이 대표적이겠네요. 

아마 운영 전환 시 그 값을 초기화하고 간다는 부분은 DB 인스턴스가 처음 실행된다는 기준으로 설계를 한 모양인가봅니다. 

일반적인 상황에서는 데이터베이스가 처음 실행되면 발생할 수 있는 그 수많은 상황들(공유버퍼가 비어있는 문제, 세션들의 쿼리 실행계획 캐시가 없는 문제,  OS 디스크 캐시에 데이터파일이 없는 문제 등등)과 같을 것 같습니다. 

그외 실행 계획이 바뀐다거나 하지는 않을 것 같습니다. 물론 운영 서버와 대기 서버의 하드웨어 사양이나, 환경 설정이 달라서 바뀌는 문제는 어쩔 수 없는 것일테고.

제가 구현하는것은 각 table의 disk space 와 row count를 보여주는 화면 인데

select count(*)하면 너무 느려서 pg_stat_user_tables table의 n_live_tuple 컬럼을 사용했었습니다.

table 크기는 8억건 정도 쌓여 있는 table 입니다.

그래서 아래 둘중의 하나 query로 해서 근사치로 보여주는것으로 수정 검토 중입니다.

SELECT reltuples::bigint AS estimate

FROM   pg_class

WHERE  oid = 'inas2.pm_reporthour'::regclass;

SELECT 100 * count(*) AS estimate FROM mytable TABLESAMPLE SYSTEM (1);

많은 조언 감사 드립니다.