Cùng một kế hoạch có thể nhanh hay chậm tuỳ dữ liệu nằm trong cache hay trên đĩa. Tuỳ chọn BUFFERS của EXPLAIN cho bạn thấy số trang shared hit so với read, chìa khoá hiểu cache lạnh và nóng — đo thật trên PostgreSQL 16.
pg_stat_statements cho bức tranh tổng thể, nhưng để bắt tận tay một câu chậm cá biệt kèm nguyên văn tham số, bạn cần log_min_duration_statement. Xem một truy vấn 98ms tự động vào log, câu nhanh thì không.
Trước khi tối ưu phải có mốc đo tin cậy. Cách dùng pgbench sinh dữ liệu lớn và đo TPS/latency thật, phân biệt tải đọc và đọc-ghi, và những nguyên tắc để con số không bị nhiễu bởi cache lạnh hay dữ liệu tí hon.
OR không tự động giết index — nó chỉ nhanh bằng nhánh chậm nhất. Đo thật: OR trên hai cột có index cho BitmapOr 0,09 ms, nhưng chỉ một nhánh thiếu index kéo cả câu thành Seq Scan toàn bảng 48 ms. Và vì sao index gộp phục vụ AND mà không phục vụ OR. PostgreSQL 16.
Trong hàng nghìn truy vấn của hệ thống thật, tối ưu cái nào trước? pg_stat_statements xếp hạng theo tổng thời gian, và số liệu thật cho thấy một truy vấn 0.007ms có thể ngốn nhiều hơn truy vấn 81ms gấp 7 lần.
Trong PostgreSQL, text và varchar lưu và chạy y hệt nhau — varchar(n) chỉ thêm một ràng buộc độ dài. Đo thật: char(50) tốn gấp đôi text vì đệm khoảng trắng, và gây bẫy so sánh khi độ dài logic khác byte trên đĩa. Vì sao char cố định nhanh hơn là huyền thoại. PostgreSQL 16.