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.
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.
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ỡ.
Đo tốc độ tiêu số hiệu giao dịch trong PostgreSQL: pgbench tám kết nối ăn 5.053 XID mỗi giây, đủ cạn 2,1 tỷ trong 4,9 ngày. Vì sao autovacuum chống-tràn-số không tắt được, và vì sao bảng lưu trữ tĩnh — chứ không phải bảng ghi nhiều — mới là bảng nguy hiểm.
Đo chi phí thật của chỉ mục thừa trong PostgreSQL: chèn chậm 4,6 lần, cập nhật chậm 5 lần dù cột được sửa chẳng nằm trong chỉ mục nào. Và ba lý do khiến idx_scan = 0 không đủ để kết luận nên xoá — kèm cách xoá an toàn bằng giao dịch thử.
Đo bộ lập lịch PostgreSQL làm việc với số liệu cũ: ước lượng 1 dòng trong khi thực tế 500.000, và một lớp bảo vệ bí mật thường cứu nó. Rồi tới kiểu sai mà ANALYZE không bao giờ chữa được — giả định các cột độc lập — và một câu lệnh sửa từ sai 66,7 lần xuống đúng.