Đo B-tree, BRIN và GiST trên bảng sự kiện 10 triệu dòng trong PostgreSQL: BRIN chỉ 32 kB, gần như miễn phí lúc ghi, nhưng nó đánh chỉ mục bố cục vật lý chứ không phải dữ liệu — xáo trộn thứ tự dòng là nó chậm 234 lần, và chết hoàn toàn trong im lặng.
Đ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 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.
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.
Đ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.