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.
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 hàng đợi công việc trong PostgreSQL: FOR UPDATE đọc lại dòng sau khi chờ được khoá — và sự bất đối xứng của việc đọc lại đó là gốc của nhiều lỗi đua tranh. Kèm con số: cỡ lô 100 nhanh gấp 48 lần cỡ lô 1, chỉ mục một phần nhỏ hơn 375 lần, và một lời cảnh báo phổ biến tôi không dựng lại được.
Đo HASH, SP-GiST và bloom trên PostgreSQL 16: HASH nhỏ hơn B-tree 8,8 lần với khoá dài vì nó chỉ lưu vân tay 4 byte thay vì cả khoá, nhưng nó chỉ biết dấu bằng — mất thứ tự, mất ràng buộc duy nhất. Và vì sao B-tree vẫn là mặc định đúng sau mười tám phần đo.
Đ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.
Đ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.