Mỗi UPDATE cột có index để lại mục chết; VACUUM dọn chúng nhưng không trả dung lượng về hệ điều hành. Đo thật: index phình từ 21 MB lên 172 MB sau 10 lần update, và vì sao chỉ REINDEX mới co lại được. PostgreSQL 16 với pgstattuple.
PostgreSQL không sửa dòng tại chỗ — mỗi UPDATE viết một phiên bản dòng mới và để lại bản cũ làm dòng chết. Đo thật: ctid đổi sau UPDATE, và 100.000 lần cập nhật một dòng logic làm bảng phình từ 8KB lên 3,5MB. Vì sao MVCC làm vậy, và HOT giảm bloat ra sao. PostgreSQL 16.
DELETE và UPDATE để lại dòng chết; VACUUM biến chúng thành chỗ trống nhưng file không nhỏ lại — đó là bloat. Đo thật: xóa 95% dòng nhưng file vẫn 269 MB, và bảng bloat đọc chậm 3,7 lần vì quét cả trang trống. Cách phát hiện bằng pgstattuple và dọn từ VACUUM FULL tới pg_repack. PostgreSQL 16.
VACUUM FULL thu nhỏ file bảng thật, nhưng đo thật: nó giữ khóa ACCESS EXCLUSIVE chặn cả đọc lẫn ghi (SELECT bị hủy vì lock timeout), cần thêm gấp đôi đĩa tạm, và downtime tỉ lệ kích thước bảng. Khi nào dùng, và vì sao production 24/7 nên dùng pg_repack. PostgreSQL 16.
pgstattuple quét cả bảng để cho con số bloat chính xác qua free_percent. Đo thật: bảng 297 MB chỉ 30 phần trăm là dữ liệu sống, 64,8 phần trăm là chỗ trống; bản approx dùng visibility map nhanh hơn 25 lần với sai số nhỏ; và pgstatindex đo bloat index riêng. PostgreSQL 16.
pg_repack thu nhỏ bảng bloat như VACUUM FULL nhưng chạy online — đọc và ghi không bị chặn. Đo thật: repack một bảng 1894 MB xuống 631 MB trong khi một SELECT đồng thời vẫn trả về 2,67 triệu dòng, thay vì bị hủy như với VACUUM FULL. Cơ chế năm bước và lưu ý production. PostgreSQL 16.