Sau năm mươi ba phần đo từng cơ chế, phần này đo cách tìm ra chỗ nào đáng đo. Kết quả đầu tiên đã đủ giật mình: cách xếp hạng phổ biến nhất — theo thời gian mỗi lần — dẫn thẳng tới việc tối ưu nhầm truy vấn, bỏ qua đúng câu đang chiếm nhiều tài nguyên nhất.
pg_stat_statements trả lời 'truy vấn nào tốn nhất'. Các khung nhìn pg_stat_* trả lời câu khác: bảng nào, chỉ mục nào, bộ đệm đang làm gì. Tôi đo chúng nói gì, ba chỗ chúng im lặng — gồm một sự cố xoá sạch mọi bộ đếm — và một dự đoán của tôi bị bác bỏ.
Năm mươi lăm phần trước đo từng cơ chế riêng lẻ; phần này ghép lại thành một quy trình gỡ truy vấn chậm và chạy trên một sự cố dựng sẵn từ đầu tới cuối. Bất ngờ lớn nhất: chỉ mục bao phủ mà ai cũng nghĩ là nhanh nhất lại tệ thứ nhì, còn chỉ mục nhanh nhất cũng là chỉ mục nhỏ nhất.
Nâng cấp phiên bản lớn là việc mỗi năm làm một lần nên chẳng ai thuộc. Tôi chạy pg_upgrade thật từ PostgreSQL 16 lên 17, đo từng bước — và tìm ra thứ nó mang theo đầy đủ lẫn thứ nó lặng lẽ để lại, đủ khiến máy chủ vừa nâng xong chậm bất thường vài giờ đầu.
Phân quyền PostgreSQL có bốn lớp, mỗi lớp chặn được một thứ khác nhau. Tôi đo từng lớp trên bảng nhân viên bốn dòng và tìm ra ba chỗ chúng không chặn — chỗ đáng nhớ nhất là một thông báo lỗi khẳng định sự tồn tại của đúng dòng mà chính sách đang cố giấu.
Đ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.