Đo bảng PostgreSQL phình lên rồi ổn định: VACUUM thường thu hồi chỗ để tái dùng nhưng giữ nguyên kích thước tệp, VACUUM FULL viết lại toàn bảng và chặn mọi truy vấn, còn autovacuum chạy chậm 25 lần vì bị hãm tốc từ thời đĩa cứng quay. Kèm cách phân biệt bloat thật với trạng thái cân bằng bình thường.
Nhìn thẳng vào các byte trên đĩa để đo MVCC: 500.000 dòng sau năm lần cập nhật chiếm 361 MB thay vì 60 MB, DELETE không giải phóng gì, và chỉ một giao dịch mở là đủ ghim mọi phiên bản cũ khiến VACUUM bó tay trên toàn cơ sở dữ liệu.
Nhiều năm liền, WITH của PostgreSQL là một hàng rào tối ưu không chuẩn SQL nào đòi hỏi: điều kiện lọc bên ngoài không được đẩy vào trong. PostgreSQL 12 đổi điều đó. Tôi dựng cả hai phiên bản với dữ liệu giống hệt để đo, và chỉ ra vì sao 'sửa' một hành vi tình cờ lại là một thay đổi phá vỡ.
Ba phép đo có kiểm soát trong PostgreSQL cho thấy hạ autovacuum_vacuum_scale_factor gần như không giảm được bloat khi tải ghi nặng — bản chỉnh tay còn phình hơn. Nút thắt thật là naptime và cost_delay, và mức phình ổn định do tốc độ ghi quyết định chứ không phải ngưỡng.
Dựng lại từng hiện tượng cô lập giao dịch bằng hai phiên chạy song song trong PostgreSQL: vì sao repeatable read không chặn được lệch ghi, và vì sao nâng lên mức cao mà không viết vòng thử lại làm biến mất 137 trong 480 lần ghi — im lặng.
PostgreSQL có đúng ba cách nối hai bảng. Tôi ép chạy cả ba trên cùng truy vấn để xem chúng chênh nhau bao nhiêu, tìm ra một dải mà lựa chọn của bộ tối ưu không phải nhanh nhất, và một lần thiếu thống kê làm truy vấn chậm 800 lần mà không báo lỗi.