delete 후 vacuum analuze 를 하셔도 DB사이즈는 줄어들지 않는걸로 압니다. full vacuum을 하시면, 줄어드는 것으로 아는데, 이 때 lock이 걸려 작업이 안되겠지요? 그래서 용량을 어느정도 확보하셔서 사이즈가 늘어나도 운영에 차질이 없게하신 후 DB사용 스케쥴에 따라 full vacuum을 해주시면 될것 같습니다.

데이터는 페이지라는 단위로 저장됩니다.

페이지 할당되고 나면 또 쓸까봐 그 물리적으로 할당된 페이지를 실재로 정리를 하지는 않습니다.

그래서, 대량 insert 가 일어났고, 대량 delete가 일어났다면,

상식적으로 그 해당 자료가 저장된 파일 크기가 별로 안 커야하는데,

DB 입장에서는 그 파일을 줄이는 일이 오히려 부담이죠.

그래서, vacuum 명령으로 이 페이지는 이제 안쓰는 페이지니 다른 자료가 저장되어도 좋다고 지정합니다.

8.4 라면, autovacuum 기능이 켜져있을터이고,

정말로 많이 기록되고, 많이 삭제되어 언제나 그 테이블의 자료는 어느 특정량 이상은 넘지 않는다면,

그 특정량 만큼의 물리적인 공간을 차지하고 있을겝니다.

2840 관련을 살펴봤는데요,

select * from pg_class where oid = 2840;

pg_toast_2619 이게 나옵니다.

select * from pg_class where oid = 2619;

pg_statistic

이게 나오네요.

즉, vacuum analyze 작업에 필요한 테이블들의 자료통계정보를 담고 있는 테이블의 토스트 자료보관용인가봅니다.

전체적으로 데이터베이스 구조가 변경사항이 없다면, pg_toast_2619 테이블의 크기(2840 파일)도 어느 정도 커지고 더이상 커지지 않아야합니다.

그런데, 계속 커진다면, 아마 계속 데이터베이스 하위객체들(테이블, 뷰, 시퀀스, column, 인덱스....)이 만들어졌다 지워졌다 하는 것은 아닐지 의문을 가져봅니다.