Bảng to gấp 10.000 lần (1k lên 10 triệu hàng) mà cây chỉ mục chỉ sâu thêm một tầng (2 lên 3), tìm một hàng vẫn đọc 6-7 trang. Tôi tưởng bảng gấp 100 lần thì tìm phải chậm hẳn — đo ra đường phẳng. Vì fanout ~360, chi phí tra cứu tăng theo log cơ số vài trăm, gần như đứng yên. Cỡ dữ liệu và chi phí tra cứu là hai thứ khác hẳn.
Một hàng 8 byte dữ liệu (2 int) tưởng 1024 hàng/trang 8KB, đo thật chỉ 226 — vì mỗi tuple còn cõng 23 byte header MVCC + con trỏ + đệm = 36 byte. Tôi nhẩm phép chia mà quên chi phí cố định mỗi hàng. Mổ trang thật bằng pageinspect: gần 78% mỗi hàng hẹp là overhead, không phải dữ liệu.
Cost một seq scan = 5406 trang × 1.0 + 1 triệu hàng × 0.01 = 15406.00, khớp EXPLAIN đến từng số lẻ. Tôi tưởng cost cố định theo dữ liệu; nhưng đổi random_page_cost là planner đổi kế hoạch dù dữ liệu y nguyên. Cost là đầu ra của một mô hình với tham số phần cứng, không phải mili giây, không phải bất biến.
Bản sao lưu hàng đêm chỉ đưa bạn về nửa đêm hôm qua. Khôi phục theo thời điểm đưa bạn về một giây trước khi ai đó gõ nhầm — nhưng chỉ khi bạn đã chuẩn bị trước tai nạn. Tôi chạy đủ quy trình từ đầu đến cuối, và cho thấy đặt mốc sai thì nó im lặng đưa bạn về nhầm chỗ.
Phân mảnh bảng hay được giới thiệu như cách tăng tốc truy vấn trên bảng lớn. Tôi đo thì thấy nó khi nhanh khi chậm; lợi ích thật nằm ở chỗ khác hẳn — DROP một phân vùng sinh 181 kB WAL thay vì 312 MB của DELETE, và không để lại một dòng chết nào.
Máy dự phòng chỉ có giá trị nếu bạn chuyển sang được. Tôi giết một máy chính đang ghi dở, thăng cấp máy dự phòng, và đo mọi thứ — kể cả phần khó hơn nhiều: đưa máy cũ quay lại mà không tạo ra hai máy chính cùng nhận ghi.