Phân trang OFFSET 0 quét 20 hàng (0,02ms), nhưng OFFSET 500000 quét 500020 hàng (34ms) và trang cuối quét cả triệu hàng (64ms). Chi phí tăng tuyến tính theo độ sâu — và tôi suýt bỏ qua vì chỉ thử trang đầu. Keyset pagination nhảy thẳng qua index, nhanh đều 0,03ms mọi trang. Vì sao OFFSET đếm còn keyset tra cứu.
Hai tiến trình tranh một CPU chia phần theo nice: 0 vs 5 ra 75/25, 0 vs 19 ra 98,5/1,5. Tôi suýt chốt 'nice 10 = chậm'. Rồi đo lại: nice 10 vs 15 chia y hệt 0 vs 5, vì phần chia chỉ phụ thuộc HIỆU nice, không phải giá trị tuyệt đối. Ưu tiên là chuyện tương đối. Đo thật.
Chọn hàm băm nhanh nhất (identity) tưởng tối ưu, nhưng với khóa có mẫu nó dồn cả triệu khóa vào 256 bucket (max 3907). SHA rải hoàn hảo nhưng tính 184 ns, gấp 240 lần hàm trộn bit cho cùng phân bố. Hàm băm tốt không phải nhanh nhất hay mạnh nhất, mà là cân bằng đúng cho dữ liệu của bạn. Tôi đo.
Thấy EXPLAIN ghi read=12760, tôi đinh ninh 12760 trang đó lôi từ đĩa lên nên hẳn phải chậm. Nhưng thời gian 17ms ổn định y hệt suốt ba lần quét — chúng do OS page cache phục vụ từ RAM, không phải đĩa. 'read' chỉ nghĩa là 'không có trong shared_buffers', không phải 'từ đĩa'. Đo tận mắt hai tầng cache, và vì sao shared_buffers to hết cỡ lại chậm hơn.
pgbench cho tôi 203189 tps read-only và tôi mừng rơn. Nhưng con số đó gần như vô nghĩa cho production: không ghi, đĩa VM fsync gần như miễn phí, 150MB nằm gọn trong RAM. Đổi bất kỳ điều kiện nào về phía thật là tps sụp mười mươi. Cách đo tải đúng với pgbench, và vì sao một con số thiếu điều kiện là một con số nói dối.
O(n log n) tốt hơn O(n²) — nên tôi định dùng merge sort cho mọi trường hợp. Nhưng đo ra ở n=64 insertion sort nhanh hơn (292 so 375 ns) vì hằng số ẩn. Big-O là hình dạng đường cong khi n tiến vô cùng, không phải tốc độ ở n cụ thể; phải đo cả đường cong, không đo một điểm. Tôi đo bằng C.