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ỏ.
Đ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ử.
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.
Advisory lock là khoá không gắn với dòng nào: 10 bản sao ứng dụng cùng khởi động một công việc định kỳ, chỉ 1 chạy, không cần bảng phối hợp. Nó không rẻ hơn khoá hàng, và có hai cái bẫy — băm tên gây va chạm, và pool kết nối giữ khoá — mà cả hai đều hỏng trong im lặng.
Đ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.
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.